Mal wieder Geistervariablen

Hallo Freunde & HQ

Wie ist denn der offizielle Stand beim Geistervariablenproblem ? Dachte eigentlich das leidige Thema sei nun schon seit längerem gefixed.
Vor einigen Monaten hatte ich auch alles aufgeräumt, und den alten Müll entsorgt.

Heute mach ich mal wieder Kontrolle und find schon wieder jede Menge Müll-Variablen bei meinen Geräten.
zb. Bewegungsmelder welche angeblich kWH gemeldet haben oder auch 500°C Temperatur oder Co2 Werte und sonstigen Blödsinn.

Wie ist dann dazu er offizielle Stand ? Gefixed oder noch in Bearbeitung ?

Falls ihr das nicht hinkriegt wäre doch vielleicht ein Workaround das man per Schalter das automatische Neuanlegen von Variablen abschalten könnte und damit die Müll Daten ins leere laufen.

schöne Grüße vom verregneten Sonntag
Bernhard

Bei mir das Gleiche :eek:

Auch werden irgendwie die Aktualisierungen von manchen FIBAROs nicht mehr in IPS übernommen …:mad:

+1, auch hier haben seit einiger Zeit manche Geräte Probleme. Wobei im Sommer merkt man net sofort wenn mal wo was falsch ist.
Darum hab ich heute mal wieder reingeschaut und war entsetzt.
Mir scheint geroutetet Geräte machen jetzt Zicken, da kommen bei einigen keine Daten mehr. Senden kann ich aber.
Hab nur leider noch keine nachvollziehbare Diagnose bin da noch am suchen.
In jedem Fall hab ich drei Geräte gefunden welche trotz Standortveränderung das Gateway partout nicht in die Routingtabelle aufnehmen wollten.
Sehr komisch und eigentlich nix das mit IPS zu tun haben kann.
Außer die Konsole die ist mir bei zWAVE nicht ganz geheuer. Mit er Legacy kriegt man einiges repariert was sich mit der Konsole sehr unklar verhält.

Aha ja, du mußt aber eine ältere Sicherungskopie der Legazy Konsole nehmen. Bei der aktuellen wirst dauernd auf die Webkonsole umgeleitet :banghead:

Naja, wird ein langer Abend heute.
Bernhard

Hallo
Ich hab das mal schon laenger aufgegeben das aufzuraeumen.
Mein Liebling ist ein Fibaro Bewegungsmelder der immer wieder neues darzu lernt :confused:
Und diese sind alle von diesem Jahr (2020)
Sieht fuer mich alles nach Daten die reinkommen „verstuemmelt“ sind oder aehnliches.

Warum noch andere Sensoren kaufen , wenn der doch (fast) alles kann. :wink:

Hallo
Hab noch ein Beispiel von mir gefunden von 2014!
Die schnellste Kaffeemaschine der Welt:
https://www.symcon.de/forum/threads/24099-Der-schnellste-Fibaro-Wall-Plug-der-Welt?p=219767#post219767

Ja,
so oder so ähnlich sieht es hier auch aus.
Aller Müll wurde in den paar Wochen/Monaten neu angelegt. Vorher hatte ich mal sauber aufgeräumt. Das weiß ich genau.

Was ich net verstehe: Auch wenn die Daten verstümmelt sein sollten, da gibt es doch eine Checksumme. Die muß doch anschlagen wenn übertragungsseitig was falsch läuft.
Das ein Hersteller Mist baut ist auch möglich, hier geht das aber quer durch. Net nur Fibaros betroffen.

bb

Das sollte eigentlich schon längst gefixt sein. Wie schnell kommen die Dinger denn? Könntet ihr einmal das „Debug to File“ aktivieren (das loggt alles in die Datei und die Konsole muss nicht offen sein), sodass ich mal Dumps zum Fehlerzeitpunkt habe? Denn es gibt Checksummen, und es wundert mich, dass diese nicht anschlagen…

paresy

Ich schalte es gerne mal ein.
Es wird aber wohl einige Zeit dauern bis da was brauchbares aufläuft.

Kann man eine Instanz überwachen ob darin eine neue Variable erzeugt wurde?
Sowas wie „On VariableCreated“.
Schau ja nicht täglich alle Instanzen durch und es passiert ja doch nur eher selten.

greez
bb

Nimm das Universal Ereignis aus dem Store und dort dann ‚Neues untergeordnetes Objekt‘ und als Objekt die Instanz.
Dann kannst du über ein Script z.b. dir eine Push Nachricht senden.
Michael

Perfekt !
Cooles Modul hast da gebaut, gefällt mir.

Bernhard

Hi Nallchan,

das Tool ist cool - leider habe ich aber scheinbar „Bedienungsprobleme“ :banghead:

M.E. funktioniert dies nur direkt die Ebene darunter - wir bräuchten doch aber irgendwas rekursives …? oder ist dies Unterschied zur Gruppe? (habe ich nicht ausprobiert:eek:)

„Naiverweise“ wollte ich mittels $_IPS[‚SENDER‘] und $_IPS[‚VALUE‘] die erstellte „Geistervariable“ ermitteln - funkt aber nicht, ich erhalte nur als Sender „UniTrigger“ und dann noch eine 5-stellige ID „10412“ - welche aber bei mir nicht existiert :eek:

Hast Du noch einen Tipp für mich?

Besten Dank im Voraus
Ciao HerbertF

Hi
Ich habe die Gruppeninstanz genommen und mehrere zu überwachende Instanzen hinzugefügt.

Das damit gestartete Script bekommt zwar nicht mit welche der Instanzen ausgelöst hat, ist aber egal.
Wenn was passiert klicke ich halt mal alle durch. Ging vielleicht noch schöner, fürs erste reicht es aber.

Mal sehen wann sich die ersten Geister zeigen.
Bernhard

@herbertf rekursiv geht nicht. Wenn aber die Variable jetzt schon vorhanden ist, unter welcher neue auftauchen, kannst du diese bestehende Variable eintragen.
Klar geht auch die Gruppe zu benutzen, und die Systemvariablen vom Modul stehen in der Doku :slight_smile:
EVENT ist das auslösende Objekt.
VALUE ist der auslösende Typ. Und unter DATA hast du die Werte welche Symcon bei dem Event sendet. Da musst du dann selber schauen wo z.b. die neue ObjektID enthalten ist.
GitHub - Nall-chan/IPSUniversalTrigger
Michael

Danke euch :wink:
Bin jetzt zwei Tage verreist :smiley: probiere ich am WE
Ciao
HerbertF

Hallo
Heute war es soweit. Einer meiner PIRIs hat „Zuwachs“ bekommen.
Um 08:50 kam eine Variable dazu „Sensor Multilevel (Leistung)“

Das Log dazu sieht so aus :

04.09.2020 08:50:22 | HEX | ® Class (31): SENSOR_MULTILEVEL | 05030A003A
04.09.2020 08:50:22 | TXT | ® Class (31): SENSOR_MULTILEVEL | <ENQ><ETX><LF><NUL>:
04.09.2020 08:50:22 | HEX | ® Class (31): SENSOR_MULTILEVEL | 05030A003A
04.09.2020 08:50:22 | TXT | ® Class (31): SENSOR_MULTILEVEL | <ENQ><ETX><LF><NUL>:
04.09.2020 08:50:22 | HEX | ® Class (31): SENSOR_MULTILEVEL | 05030A003A
04.09.2020 08:50:22 | TXT | ® Class (31): SENSOR_MULTILEVEL | <ENQ><ETX><LF><NUL>:
04.09.2020 08:50:22 | HEX | ® Class (31): SENSOR_MULTILEVEL | 05030A003A
04.09.2020 08:50:23 | TXT | ® Class (31): SENSOR_MULTILEVEL | <ENQ><ETX><LF><NUL>:
04.09.2020 08:50:23 | HEX | ® Class (31): SENSOR_MULTILEVEL | 05030A003A
04.09.2020 08:50:24 | TXT | ® Class (31): SENSOR_MULTILEVEL | <ENQ><EOT>"<NUL><NUL>
04.09.2020 08:50:24 | HEX | ® Class (31): SENSOR_MULTILEVEL | 0504220000
04.09.2020 08:50:26 | TXT | ® Class (31): SENSOR_MULTILEVEL | <ENQ><ETX><LF><NUL>:
04.09.2020 08:50:26 | HEX | ® Class (31): SENSOR_MULTILEVEL | 05030A003A
04.09.2020 08:50:28 | TXT | ® Class (31): SENSOR_MULTILEVEL | <ENQ><ETX><LF><NUL>:
04.09.2020 08:50:28 | HEX | ® Class (31): SENSOR_MULTILEVEL | 05030A003A
04.09.2020 08:50:30 | TXT | ® Class (31): SENSOR_MULTILEVEL | <ENQ><ETX><LF><NUL>:
04.09.2020 08:50:30 | HEX | ® Class (31): SENSOR_MULTILEVEL | 05030A003A
04.09.2020 08:50:32 | TXT | ® Class (31): SENSOR_MULTILEVEL | <ENQ><ETX><LF><NUL>:
04.09.2020 08:50:32 | HEX | ® Class (31): SENSOR_MULTILEVEL | 05030A003A
04.09.2020 08:50:34 | TXT | ® Class (31): SENSOR_MULTILEVEL | <ENQ><ETX><LF><NUL>:
04.09.2020 08:50:34 | HEX | ® Class (31): SENSOR_MULTILEVEL | 05030A003A

Sonst immer :

04.09.2020 08:50:23 | HEX | ® Class (31): SENSOR_MULTILEVEL | 05030A003A

dann das :

04.09.2020 08:50:24 | HEX | ® Class (31): SENSOR_MULTILEVEL | 0504220000

Hallo
Die Checksummen werden wohl nicht geloggt oder ?
Als Beispiel eine Helligkeitsvariable, da aendert sich ausser dem Wert nichts:

® Class (31): SENSOR_MULTILEVEL | 05030A0198 (= 0198H = 408 Dezimal 408,0 Lux)
® Class (31): SENSOR_MULTILEVEL | 05030A0109 (= 0109H = 265 Dezimal 265,0 Lux)

Hallo
Gestern wieder eine neue Variable dazugekommen.
Bei einem PIRI-Sensor mit NodeID = 24 wurde eine Variable erstellt:
Sensor Multilevel (Generelle Verwendung) mit Wert 320.
Uhrzeit : 07.09.2020 14:37:11

Diese Mal das Log vom der Z-Wave IO Instanze:

07.09.2020 14:37:11 | HEX | RECEIVED | 01
07.09.2020 14:37:11 | HEX | RECEIVED | 14000400
07.09.2020 14:37:11 | HEX | RECEIVED | 350C600D0303
07.09.2020 14:37:11 | HEX | RECEIVED | 310501440000
07.09.2020 14:37:11 | HEX | RECEIVED | 0934BF0048
07.09.2020 14:37:11 | HEX | TRANSMIT | 06
07.09.2020 14:37:11 | HEX | RECEIVED | 010E0004100A063105030A0101CA001E
07.09.2020 14:37:11 | HEX | TRANSMIT | 06
07.09.2020 14:37:11 | HEX | RECEIVED | 010E0004100A063105030A
07.09.2020 14:37:11 | HEX | RECEIVED | 0101AE007A
07.09.2020 14:37:11 | HEX | TRANSMIT | 06
07.09.2020 14:37:11 | HEX | RECEIVED | 010E
07.09.2020 14:37:11 | HEX | RECEIVED | 0004101806
07.09.2020 14:37:11 | HEX | RECEIVED | 3105030A0140
07.09.2020 14:37:11 | HEX | RECEIVED | C30044
07.09.2020 14:37:11 | HEX | TRANSMIT | 06
07.09.2020 14:37:11 | HEX | RECEIVED | 010E
07.09.2020 14:37:11 | HEX | RECEIVED | 0004100A06
07.09.2020 14:37:11 | HEX | RECEIVED | 310503020101
07.09.2020 14:37:11 | HEX | RECEIVED | C3001F
07.09.2020 14:37:11 | HEX | TRANSMIT | 06
07.09.2020 14:37:11 | HEX | RECEIVED | 010E
07.09.2020 14:37:11 | HEX | RECEIVED | 0004101806
07.09.2020 14:37:11 | HEX | RECEIVED | 3105020A0140
07.09.2020 14:37:11 | HEX | RECEIVED | C40042
07.09.2020 14:37:11 | HEX | TRANSMIT | 06
07.09.2020 14:37:11 | HEX | RECEIVED | 010E
07.09.2020 14:37:11 | HEX | RECEIVED | 0004100A0631
07.09.2020 14:37:11 | HEX | RECEIVED | 05030A0101D7
07.09.2020 14:37:11 | HEX | RECEIVED | 0003
07.09.2020 14:37:11 | HEX | TRANSMIT | 06
07.09.2020 14:37:11 | HEX | RECEIVED | 010E0004100A063105030A0101CD0019
07.09.2020 14:37:11 | HEX | TRANSMIT | 06
07.09.2020 14:37:11 | HEX | RECEIVED | 01
07.09.2020 14:37:11 | HEX | RECEIVED | 0E000410
07.09.2020 14:37:11 | HEX | RECEIVED | 18063105030A
07.09.2020 14:37:11 | HEX | RECEIVED | 0140CA004D
07.09.2020 14:37:11 | HEX | TRANSMIT | 06
07.09.2020 14:37:11 | HEX | RECEIVED | 010E00
07.09.2020 14:37:11 | HEX | RECEIVED | 04101806
07.09.2020 14:37:11 | HEX | RECEIVED | 3105030A0140
07.09.2020 14:37:12 | HEX | RECEIVED | D70050

Denke es handelt sich um diese Eintraege:

07.09.2020 14:37:11 | HEX | RECEIVED | 010E
07.09.2020 14:37:11 | HEX | RECEIVED | 0004101806
07.09.2020 14:37:11 | HEX | RECEIVED | 3105030A0140
07.09.2020 14:37:11 | HEX | RECEIVED | C30044

07.09.2020 14:37:11 | HEX | RECEIVED | 010E
07.09.2020 14:37:11 | HEX | RECEIVED | 0004101806
07.09.2020 14:37:11 | HEX | RECEIVED | 3105020A0140
07.09.2020 14:37:11 | HEX | RECEIVED | C40042

07.09.2020 14:37:11 | HEX | RECEIVED | 010E00
07.09.2020 14:37:11 | HEX | RECEIVED | 04101806
07.09.2020 14:37:11 | HEX | RECEIVED | 3105030A0140
07.09.2020 14:37:12 | HEX | RECEIVED | D70050

Hallo
Hab das mir mal genauer angesehen.
Das sollte Korrekt sein:

07.09.2020 14:37:11 | HEX | RECEIVED | 0004101806
07.09.2020 14:37:11 | HEX | RECEIVED | 3105030A0140

fuer SensorMultilevel03Variable (Beleuchtung).
Der Wert im Archiv dafuer ist auch korrekt mit 320lx.

Das ist wohl falsch:

07.09.2020 14:37:11 | HEX | RECEIVED | 0004101806
07.09.2020 14:37:11 | HEX | RECEIVED | 3105020A0140

Deshalb wird eine SensorMultilevel02Variable erstellt mit Wert 320.

Vielen Dank, auch wenn dies echter Mist ist. Da einfach Bytes „kippen“ kann ich dagegen gar nichts tun. Das ist bereits nach dem CRC Check, sodass der Fehler direkt im Z-Wave Gerät passieren muss, bevor die Daten gesendet werden.

Ich werde einen Experten Schalter bauen, der Multi-Level Variablen sperren kann. (Es betrifft nur diese, korrekt?)

paresy

Hallo
Ich persoenlich hab bis jetzt nur Multilevel Variablen gesehen.