[gelöst] Eingeschaltete Verbraucher überwachen
-
@jan1
Das mit der Konvertierung macht mich auch etwas stutzig. Meine verwendeten Objekte sind alle "bool". Trotzdem kommt die schon oben erwähnte Fehlermeldung im Log, wenn ich die Konvertierung nicht einfüge.
Ich habe drei Stockwerke mit je ca. 10 Objekten. In der Visu habe ich für jedes Stockwerk einen Indikator (bool) eingebaut, der anzeigt, dass noch nicht alle Objekte (Leuchten) aus sind.
Nach meinem Kentnisstand habe ich ein logisches "oder" über die Objekte mit meinem Blockly gebaut, das - bis auf die Konvertierung - so funktioniert wie gedacht.
Das das ein Zufallsprodukt sein soll, kann ich nicht glauben. Ich kann auch mal den Code des Blocklys hier einstellen, dann können die Spezialisten nachsehen, warum es funktioniert.
Hans -
@tontechniker
Das ist ein Zufallsprodukt
Wenn das wirklich boolen sind, dann ist die Konvertierung überflüssig.
Ich fasse jetzt noch mal zusammen, was Du überhaupt machen willst.Beleuchtung Garten soll auf true wechseln, wenn Rundumleuchten oder Wege true sind, richtig?
Wenn ja dann poste mal bitte den Export, damit ich das so umbaue, wie es für mich am logischsten wäre. -
@jan1
Ich schicke Dir mal ein komplettes Stockwerk.
Erster Stock.txt
Und hier das einfache Beispiel.
Garten.txt
Danke! -
@tontechniker
So und hier mein Vorschlag den ich wesentlich logischer finde:
Dann noch ein Tipp für die Übersicht, rechte Maustaste auf den Block und "externe Eingänge" wählen
@paul53
könnte man sich das viele Oder in der FALLS auch mit "ist wahr" im Trigger und WERT in der FALLS noch verkürzen? -
@tontechniker sagte: Ich kann auch mal den Code des Blocklys hier einstellen, dann können die Spezialisten nachsehen, warum es funktioniert.
Das nutzt nichts, da wir nicht nachvollziehen können, was die Trigger-Datenpunkte liefern. Bau besser zwei Debug-Blöcke für die Log-Ausgabe der beiden Datenpunkt-Werte ein.
-
@jan1 sagte: könnte man sich das viele Oder in der FALLS auch mit "ist wahr" im Trigger und WERT in der FALLS noch verkürzen?
Nein.
-
@paul53
Hatte ich mir gedacht, da der Trigger hier leider nicht als ODER fungiert und die Zuordnung WERT wohl auch nicht so ist wie es bei einem einzelnen Objekt wäre, schade da man so alles doppelt angeben muss.@Tontechniker
Der RAW eines der Trigger DPs wäre hier auch nützlich, da man da sieht wie der deklariert ist. -
@jan1 sagte: Der RAW eines der Trigger DPs wäre hier auch nützlich, da man da sieht wie der deklariert ist.
Aber nur dann, wenn sich die Werte im Datenpunkt an die Deklaration halten, was leider nicht immer der Fall ist.
-
@paul53
Die Anbindung der Geräte erfolgt wohl über den KNX Adapter, der auch die Objekte generiert. Ist das dann nicht automatisch richtig? -
@jan1 sagte: KNX Adapter, der auch die Objekte generiert. Ist das dann nicht automatisch richtig?
Ich weiß nicht, ob der KNX-Adapter alle Datenpunkte richtig behandelt (habe kein KNX).
-
@tontechniker sagte: Meine verwendeten Objekte sind alle "bool".
Der Javascript-Adapter denkt sich das nicht aus:
You are assigning a number to the state "0_userdata.0.Überwachte_Verbraucher.Beleuchtung_Garten" which expects a boolean. Please fix your code to use a boolean or change the state type to number -
@jan1
Habe alle Blocklys so wie Du vorgeschlagen umgestellt. Es funktioniert ohne Konvertierung.
Vielen Dank!
Gruss
Hans -
@paul53
Du vermutest richtig. Alle Datenpunkte kommen von KNX. Deshalb konnte ich mir die Fehlermeldung nicht erklären. Ich glaube, ich habe mit meiner ersten Version ein "feature" entdeckt und mit der Konvertierung den dabei entstehenden Fehler ausgebügelt. -
@tontechniker
Und wenn Dir das jetzt anschaust, sieht das auch logischer aus, oder?
Ehrlich wenn das nicht funktioniert hätte, hätte ich immer noch nicht verstanden, was Du eigentlich tun willst
-
@jan1 sagte: Und wenn Dir das jetzt anschaust, sieht das auch logischer aus, oder?
Eigentlich nicht, wenn die Datenpunkte tatsächlich boolesche Werte liefern würden. Falls (if) macht eine implizite Typwandlung, wenn die Oder-Verknüpfung eine Zahl liefert.
-
@paul53
Von der Funktion ist was anderes, wenn man noch nicht weiß, was da wirklich im DP drin steht.
Ich meinte auch die Optik, da man hier eigentlich sehr schnell und einfach sehen kann, was das Blockly tun soll. Das war vorher auch mein Problem, dass irgendwie das was er geschrieben hat, nicht zu dem Blockly gepasst hat, was angeblich sogar das tut was es soll.Da das jetzt auch ohne Konvertierung und Fehler im Log läuft, war wohl vorher noch wo ein Fehler begraben.
-
@jan1 sagte: Da das jetzt auch ohne Konvertierung und Fehler im Log läuft
Die Konvertierung erfolgt jetzt nicht durch einen Konvertierungs-Block, sondern implizit durch den falls-Block.
-
@paul53
Ist das dann wieder die Typwandlung wie oben schon geschrieben? Wobei ich davon ausgegangen bin, dass der Block nur auf true und false regiert. Aber selbst wenn, müsste das nicht auch im Log auftauchen? -
@jan1 sagte: dass der Block nur auf true und false regiert.
Der falls-Block reagiert auf alle Datentypen und macht bei nicht booleschen Werten eine implizite Typwandlung.
Kleiner Test (variiere den Zahlenwert):
@jan1 sagte in Eingeschaltete Verbraucher überwachen:
müsste das nicht auch im Log auftauchen?
Das Log warnt nur, wenn bei setState() der Datentyp des geschriebenen Wertes nicht mit der Deklaration in common.type übereinstimmt.
-
@paul53
Hätte nicht gedacht, dass ich bei so einer leichten Aufgabe noch dermaßen viel dazu lerne. Ich habe schon verstanden was da passiert und warum, war mir nur nicht bewusst, dass das so schon automatisch abläuft.Dass das nur bei setState passiert ist dann auch klar, da er hier eben auch gleich ein eventuelles Folgeproblem anmeckert. Beim Einlese ist es dem Block wurscht, da er es eh so konvertiert wie er es versteht. Merkt man dann eventuell erst, wenn was rauskommt, was man so nicht erwartet
