Also ich habe inzwischen noch keine neuen Variablen gefunden.
Verstehe natürlich das du bei korrektem CRC nichts machen kannst.
Komisch kommt mir das trotzdem vor. Wenn nur eine Gerätetype eines Herstellers betroffen wäre, dann wäre es nachvollziehbar. Hat der halt ein Problem in seinem Design.
Wir sehen das aber bei verschiedenen Herstellern. Und das alle den selben Bug haben sollen ist schon merkwürdig. Es sei denn die CRC Berechnung passiert im Transceiver selbst, denn hier verwenden wohl alle die selben Chips von SigmaDesign.-
Wegen Multilevel: Ich habe beim Aufräumen nicht explizit darauf geachtet ob es nur Multilevel Variablen waren. Könnte aber sein.
Wäre nicht ein entsprechender Switch bei der jeweiligen Instanz besser als dies in die Experteneinstellungen zu packen ?
@1007: Da es bei dir öfters passiert - könntest du mir evtl. das Debug vom Gateway ebenfalls mitloggen, sodass ich die kompletten Datenpakete hätte? @bb hat da definitiv Recht - vielleicht sollte ich noch einmal tiefer graben, ob wir irgendwo anders einen Fehler machen.
Gestern hast du geschrieben , dass im Log vom Lan_Adapter (IO) die CRC Berechnung schon passiert ist.
Also im LAN-Adapter selbst ( Hardware ) bevor es im Server ankommt.
CRC kann man hier zum Test berechnen lassen: Online Checksum Calculator - SCADACore Dabei die 01 vorne weglassen und stattdessen ein FF davor tun, da Z-Wave den CRC Generator mit FF initialisiert. Und natürlich das letzte Paar z.B. 33 auch weglassen. Das ist dann auch der CRC der dort berechnet wird. Diese stimmt bei den oberen Paketen jeweils.
Bedeutet somit, dass die Checksumme auch bei den fehlerhaften Daten korrekt ist
Könnt ihr einmal nachsehen, welche Version von SENSOR_MULTILEVEL eure Geräte unterstützen?
Das wäre super. Ab Multilevel Version 5 liefern die Sensoren, welche Variablen diese unterstützen. D.h. dort könnte ich einbauen, dass einfach immer nur die gemeldeten/unterstützen erlaubt sind.
Hi
habe zwar noch keine neuen Geister, aber was sinnvolles beitragen zu können in einem Backup von letzter Woche nachgesehen:
Es ist definitiv nicht nur die MultilevelClass31 betroffen. Auch Notification Class71 macht Müll.
Dann hab ich aber auch Thermostate (!) welche eine Beleuchtung Multilevel Variable mit sinnvollem Inhalt haben. (bei doppel CRC Fehler wäre IMHO doch ein unsinniger Inhalt zu erwarten) . Die Daten gehören also eindeutig zu einem Bewegungsmelder !
Sieht so aus als ob es auch passieren kann das offensichtlich korrekte Telegramme falschen Nodes zugeordnet werden.
Habe Geräte mit falschen Multilevel Class31 Variablen in Versionen 1,5,7 alle von verschiedenen Herstellern.
Es gibt auch noch merkwürdige Nicht-Multilevel Variablen. Siehe Screenshot:
Bewegungsmelder Parkplatz hat Version 7
Bewegungsmelder Badezimmer Version 1
Da hier zumindest 4 Hersteller mit ganz unterschiedlichen Geräten und Meldungsklassen betroffen sind riecht es doch danach als ob da etwas im Gateway passiert.
Ich hab einen UZB1. (wie ich beiläufig feststellen mußte mit einer offensichtlich etwas veralteten Firmwareversion, NVM Download wird von dessen APi Version nicht unterstützt) @1007: was verwendest du ?
mit akzeptablen Logs kann ich leider derzeit nicht dienen, habe aber mal ein paar Snapshots benannt. Neben dem Problem der Geistervariablen finde ich fast noch störender, dass bei manchen Geräten zwar der Status aber nicht die Messwerte aktualisiert werden - nur bei manuellem Aufruf in IPS - dies ging bei den Geräten schon definitiv!
Bei einem Qubino-Dimmer führe ich jetzt zyklisch
ZW_RequestStatus($ParID);
aus - dies kann es nicht sein. Bei FIBARO-Dimmern habe ich den gleichen Eindruck, komischerweise funktionieren die
FIBARO-Roller-Shutter aber hier top - ständig die Leistung obwohl die mich Null interessiert.
Ich habe jetzt viele - meiner ca. 100 Geräte durchgeklickt. Geistervariablen Schwerpunkt eindeutig bei Bewegungsmeldern, am meisten Fibaro aber auch andere…
Hallo, hab da noch einen Input.
Letztens war ja weit über eine Woche lang nichts von Geistervariablen zu sehen.
Während der letzten 3 Tage hab ich wegen Umbau vom Zählerkaten dem IPS Rechner mehrmals ohne vorher runterzufahren vorherunsanft den Strom abgedreht.
Siehe da da haben sich plötzlich wieder einige Geister blicken lassen. Leider hab ich kein logfile, weil ja bei Neustart das Log-to-File abgedreht wird. Vorwiegend sind es Geistervariablen vom Typ „Notification“
Kann Zufall sein, muß aber nicht.
Ah ja, alle bei batteriebetrieben Nodes die haben von den Stromausfällen nichts mitgekriegt.
Könnte dies die Ursache für unsere Geistervariablen sein ?
Ich sehe hier bei Nodes welche die Klasse 56 CRC16 Encap unterstützen zzt. keine Geister.
Welche ohne Klasse 56 haben welche. Allerdings habe ich erst kürzlich mal aufgeräumt sagt also nicht viel.
Was ich aber nicht verstehe: Der Text suggeriert das zWavePlus diese CRC16 Klasse zwingend vorschreibt.
Allerdings wird die sie bei einem meiner Problemkind NICHT angezeigt, obwohl die Klasse 5E vorhanden ist. Und das Teil lt. Manual auch zWavePlus hat.
Servus
Wollte das jetzt mal ausprobieren, aber da stellt sich mir ein Verständnisproblem.
So wie es implementiert ist ist er Schalter für jedes Gerät einzeln zu aktivieren. Macht das Sinn ?
Wie wir festgestellt haben tauchen die Geistervariablen ja sporadisch irgendwo auf. Man müßte also alle Geräte durchklicken und sperren. Hmm.
Hätte mir eher erwartet das der Schalter im Konfigurator auftaucht und dann global wirkt.
Die Luxusversion wäre gewesen wenn der komplette Workflow so gestaltet wäre das er sich automatisch aktivieren und deaktivieren kann. Aber wer will schon Luxus…
Mercy -
schlage vor das Script in die zWave Doku mit aufzunehmen.
Bin sicher nicht der einzige der das praktisch findet.
Weil wie gesagt, die Variablen tauchen potentiell überall auf, da macht es auch gar keinen Sinn das nur an manchen Devices Einzuschalten.
So, habe die neueste Version installiert und den Schalter „keine neuen Variablen“ aktioviert. Trotzdem erstellen sich wieder diese unnötigen Variablen. Also Hat nix gebracht
