@__deets__
Bin noch mitten in meiner Antwort, da kommt schon der nächste Post
Okay, erstmal zu deinem Text vom Wochenende:
das die clients in deinem Diagramm Zugriff auf die Datenbank erhalten - und nicht nur der Server - halte ich fuer uengluecklich. Das deutet eine Menge Probleme in meinen Augen: als client-Entwickler muss ich *zwei* APIs - Server & DB - bedienen, eine davon nagelt mich auch noch auf eine spezifische Datenbanktechnologie fest, und last but not least kann ich damit wahrscheinlich dieselben Dinge auf mindestens zwei, im Zweifel auf gemischet 3000 Arten erledigen. Standardisiere das auf das JSON-basierte Netzwerkprotokoll.
Hmm, für mich sah das nach weniger Arbeit aus, ansonsten müsste ich ja alles per websockets & json senden.
Ich werde aber auf jeden Fall darüber nachdenken, ist auf jeden Fall ne ganze Menge an Arbeit wenn ich das jetzt umstellen will.
die Darstellung der JSON-Formate als Tabelle ist unorthodox, und vermittelt mir ueberhaupt nicht, was du da erwartest.
Okay, ich war der Meinung das die Tabelle deutlich macht wie ich das "Protokoll" verstehe.
Ich habe leider null Erfahrung mit sowas und weiß nicht wie ich meine Gedanken am besten zu "Papier" bringe.
Zahlwerte in deutsche Schreibung mit Komma haben in JSON entweder nichts verloren, oder werden ineffizient als Strings uebertragen - kann ich mir fast nicht vorstellen.
Der Teil der Software hat mit den Sensoren zu tun und ist über 1 Jahr alt.
Wenn ich demnächst zu den Sensoren komme, werde ich mir das anschauen und dann entsprechend anpassen.
Echte JSON-Nachrichten sind da sinnvoller. Spaeter sieht man, dass du immer Arrays meinst. Halte ich fuer wenig sinnvoll - statt Reihenfolge sollte man lieber ein Objektliteral mit diversen definierten und ggf. optionalen Schluesseln waehlen.
Den letzten Satz verstehe ich nicht, kannst du mir bitte dazu ein Beispiel geben?
es gibt in Python Stringliterale mit dreifachen Anfuehrungszeichen - damit schreibt man mehrzeilige Strings einfach, statt so eine \-Verkettungsorgie zu feiern.
Was meinst du damit?
wirklich *einfach* erweiterbar ist das System laut des gezeigten Quellcodes nicht. Die grosse if-Kaskade, um Schaltertypen anzulegen, ist unschoen. Vor allem hast du an anderen Stellen standardisierte Schnittstellen, mit generisch benannten Argumenten irgendeiner Art - aber mit einem mal bekommen alle Klassen ihre ganz persoenlichen Argumente uebergeben.
Ja, das hast du leider Recht und wenn ich wüsste wie, dann würde ich es gerne ändern.
Auf die if-Kaskade verzichten und allen Klassen die gleichen Argumente übergeben wäre natürlich besser, scheitert aber wie gesagt noch an meinem (nicht vorhandenen) Können.
Wenn das standardisiert abliefe, koenntest du eine simples Factory-Pattern verwenden, und das ggf. mit einem Plugin-System kombinieren, um neue Schalter-Typen anzulegen.
Auch hier verstehe ich gerade nur Bahnhof, eventuell würde mir ein kleines Beispiel helfen.
Ob das sinnvoll ist, kann ich schwer beurteilen. Ich glaube ja, es waere zielfuehrender, ueber die entsprechende Server JSON API diverse Typen - an/aus, stufenloser regler usw - anzubieten - und das war's dann auch schon. Gar kein Grund, da grossartig Code fuer zu schreiben - ob hinter einem Schalter nun ein PI oder ein Arduino oder was auch immer steckt, muss den Server meistenteils doch gar nicht interessieren. Da sind viel eher Fragen nach Gruppierung und Automatisierung relevant.
Dafuer wandern dann deine ganzen Tinkerforge-dieses und GPIO-jenes in eigenstaendig laufende Programme, die wissen dann halt, was sie wissen muessen.
Hier bin ich noch dabei zu verstehen was du mir sagen willst, bzw. ob das für mich so umsetzbar ist.
m Quellcode habe ich property-Deklarationen gefunden, die nicht mit Dekorator gemacht wurden - das ist meiner Erinnerung schon seit Python 2.4, also ungefaehr 12 Jahren, nicht mehr so ueblich.
Verstehe ich (noch) nicht. Arbeite aber dran
es findet sich Code wie folgender:
...
...
Da ist viel komisch. Es faengt an mit dem komplett identischen Code fuer beide Faelle - da sollte also eine vereinheitlichte Bedingung benutzt werden, und nur einmal der Code.
Die Aufrufe "switch_socket_b" und "switch_socket_c" sind so von der API des Hersteller vorgegeben.
Würde das auch gerne in eine Zeile packen, nur wie?
Ich kann ja an der API nichts ändern.
Das pass ist ueberfluessig.
Das gehört eigentlich auch weg.
Habe ich wohl übersehen und dann vergessen zu löschen.
Die switched-Variable wird danach sofort benutzt in einem if - sie koennte also weg, und der entsprechende Code einfach eingerueckt darunter.
Das würde aber nur gehen wenn ich die API-Aufrufe irgendwie in eine Zeile bekommen würde oder wie meinst du das?
Wenn ich den Code darunter einrücke, dann betrifft das ja nur die 2. if-Abzweigung oder ich schreibe es bei beiden direkt drunter.
Dann spare ich mir die Variable "switched", habe aber doppelten Code.
Oder verstehe ich da etwas ganz falsch?
Die Konstanten sind unerklaert und magisch, die Werte (mit Leerzeichen) eher unueblich gewaehlt, die generischen Argumentnamen unklar.
Hier stehe ich gerade auf dem Schlauch. Auf was beziehst du dich, auf welche Konstanten?
Die Werte ergeben sich über die Datenbankeinträge für den jeweiligen Schalter.
Kann ja mir der einen Hardware theoretisch hunderte von Schaltern nutzen, deswegen muss ich etwas flexibel sein und kann nicht alles direkt in den Code schreiben.
Okay, das Leerzeichen hätte man weglassen können
Die Argumentnamen erkläre ich eigentlich im Blog und die werden etwas klarer wenn man sich im Frontend die Beispiel-Schalter ansieht.
Hoffe ich zumindest.
Du hast dir hier mit dem "b switch" & Co aber auch ein schönes Beispiel ausgesucht, dieses Modul (TF RemoteSwitch) ist noch nicht ganz fertig.
Soll aber keine Ausrede sein.
wann ein Attribut bei dir privat oder oeffentlich ist folgt keinem mir erkennbaren Schema
Eigentlich sollen alle temporären Variabeln privat sein.
Zu Beginn habe ich alle mit einem "__var" versehen.
Irgendwann hat man mir aber gesagt das würde man nicht mehr machen.
Deswegen ist es jetzt etwas durcheinander.
Soviel schon mal zu deinem ersten Post.
Ja, ich weiß es gibt schon einen neuen.
Wie du sicherlich gemerkt hast bin ich kein Profi, im Gegenteil, ich arbeite in einer Schreinerei im Büro.
Von daher ist es schon bitter zu sehen wie wenig ich doch richtig mache.
Es würde mich freuen wenn du auf meine Frage kurz eingehen könntest.
Ich werde in den nächsten Tagen nachdenken und schauen wie ich deine Ideen eventuell umsetzen kann.
Jetzt zu deinem neuen Eintrag ...
