[erledigt] nach 1 jahr betrieb neue, sinnlose readings?

[the ratman]

hiho

ich hab 2 "Fibaro FIBEFGMS-001-ZW5 5G 4-in-1 Multisensor".
seit heute gibts bei einem neue readings:

Code Auswählen Erweitern

particulateMatter 49 micro-g/m3
tankCapacity 0 cbmdas ganze rennt über nen usb-stick.
ich bin etwas verwirrt. kann mir da jemand auf die sprünge helfen?

[A.Harrenberg]

Hi,

das dürften Pakete sein die wegen Übertragungsfehler mehrfache bitfehler haben aber bei denen die Checksumme dann doch wieder gestimmt hat. Leider ist die Checksumme im ZWave Protokoll sehr einfach gehalten... Readings löschen und ignorieren.

Gruß,
Andreas.

[the ratman]

thx für die info - bin ich beruhigt.

zum glück hab ich ja nur mehr 2 stk. zwave. sobald ich die beim fenster raus gekübelt hab, ist bis aufs licht alles homematik. dann ist endlich ruhe mit den komischen dingern.

[DeeSPe]

Ich habe mittlerweile eine ganze Liste an lustigen Readings die sich so auf meinen Z-Wave Geräten ansammeln und die ich hin und wider lösche.
Es handelt sich immer um Readings die das Gerät auf keinen Fall besitzen kann.

Hier mal eine kleine Liste was ich so schon alles gelöscht und in supressReading eingefügt habe:
Fibaro Motion Sensoren:

Code Auswählen Erweitern

barometricPressure
direction
generalPurpose
particulateMatter
position
power
time
tankCapacity
dewpoint
volatileOrganicCompound
CO2-level
humidity

Und diese bei den Fibaro Wall Plugs:

Code Auswählen Erweitern

alarm_type_04
battery
humidity
direction
luminance
temperature
velocity
wakeup
rain
formaldehydeLevel
electricalResistivity
undef
water
distance

Gruß
Dan

[tomspatz]

Hier mal eine kleine Liste was ich so schon alles gelöscht und in supressReading eingefügt habe:

Das muss dann allerdings bei jedem device einzeln eingetragen werden.
"global" fällt ja in diesem Falle weg.
Schade

[DeeSPe]

Das muss dann allerdings bei jedem device einzeln eingetragen werden.
"global" fällt ja in diesem Falle weg.
Schade

Genau!

Gruß
Dan

[krikan]

Hier mal eine kleine Liste was ich so schon alles gelöscht und in supressReading eingefügt habe:

Die schönere Lösung wäre, wenn wir die Command Class CRC16 Encapsulation erforschen und für den Versand einbauen würden. Dann wäre das Problem afaik behoben, wenn ich die CC richtig verstehe. Mir ist noch nicht klar, wie man bei spontanen Nachrichten die CRC16 erzwingt; das habe ich bisher nicht sicher experimentell hinbekommen. Bei get-Abfragen funktioniert das automatisch: Wenn get-Abfrage CRC16 gekapselt ist, dann kommt auch CRC16 zurück. Weiteres Problem: Bei 100k Routen ist CRC16 überflüssig und verursacht unnötigen Overhead. Also müsste man das im Oprimalfall auch noch bei den Routen nach 100k und 40k im Versand unterscheiden!?

[A.Harrenberg]

Hi Christian,

Die schönere Lösung wäre, wenn wir die Command Class CRC16 Encapsulation erforschen und für den Versand einbauen würden. Dann wäre das Problem afaik behoben, wenn ich die CC richtig verstehe.

zumindest ist die Checksumme dann weniger tolerant gegenüber Fehlern, eine 100% Sicherheit ist es dann zwar immer noch nicht, aber um Größenordnungen besser als die einfache Standard-Checksumme.

Mir ist noch nicht klar, wie man bei spontanen Nachrichten die CRC16 erzwingt; das habe ich bisher nicht sicher experimentell hinbekommen. Bei get-Abfragen funktioniert das automatisch: Wenn get-Abfrage CRC16 gekapselt ist, dann kommt auch CRC16 zurück.

Das die Antwort so generiert wird wie die Anfrage ist ja im ZWave-Standard so vorgesehen. Ob sich das Device dann für die spontanen Nachrichten den Zustand merkt wäre geschickt, aber das müsste man wirklich mal probieren.

Weiteres Problem: Bei 100k Routen ist CRC16 überflüssig und verursacht unnötigen Overhead. Also müsste man das im Oprimalfall auch noch bei den Routen nach 100k und 40k im Versand unterscheiden!?

Problem dabei ist herauszubekommen ob eine Route nun wirklich 100K ist oder vielleicht ja über ein 40K geroutet wird. Ausserdem schalten die Dinger bei Übertragungsproblemen auf 40k runter wenn ich das richtig in Erinnerung habe. Und das wird vom Dongle nicht gemeldet, "wir" wissen letztendlich nicht ob ein 100k Gerät auch wirklich mit 100k sendet.

Das wird spannend!

Gruß,
Andreas.

[krikan]

Ob sich das Device dann für die spontanen Nachrichten den Zustand merkt wäre geschickt, aber das müsste man wirklich mal probieren.

Habe ich leider nicht definitiv feststellen können. Hatte vor laengerer Zeit mit einem Fibaro FGMS experimentiert und eigentlich den Eindruck, dass der sich das merkt, da eine Zeit lang nur noch CRC16-Nachrichten kamen. Aber dann kam die Ernüchterung nach einigen Stunden: Plötzlich waren die Nachrichten wieder ohne CRC16 und ich hatte die Lust am Thema verloren. Ob das an einem Fehler in meinem CRC16-Stackversandmanipulations-Spagetti-Code lag oder andere Ursachen hatte, habe ich nicht mehr analysiert.

Problem dabei ist herauszubekommen ob eine Route nun wirklich 100K ist oder vielleicht ja über ein 40K geroutet wird. Ausserdem schalten die Dinger bei Übertragungsproblemen auf 40k runter wenn ich das richtig in Erinnerung habe. Und das wird vom Dongle nicht gemeldet, "wir" wissen letztendlich nicht ob ein 100k Gerät auch wirklich mit 100k sendet.

Ist ja nur die Kür. Keine Ahnung, ob uns dabei evtl. routeFor von ZWDongle hilft.

Gruß, Christian

[A.Harrenberg]

Hi,

ich bin zeitgleich noch in einem Thread wo jemand einen CU(L|N) mit 4x Radio + 2 UART auf Basis von einem MAPLE-Mini baut. Ich habe mir mal ein paar Platinen reserviert. Wenn das so klappt wie ich mir das vorstelle könnte man da 3 CC1101 mit 868MHz drauf machen und die fest auf 9.6k, 40k und 100k stellen und dann (hoffentlich) als stacked_cc mit ZWCul einbinden.

Damit hätten wir dann das ultimative sniffing-device, damit könnte man dann auch unterscheiden mit welcher Geschwindigkeit gesendet wurde.

Allerdings habe ich momentan weder die Platine, noch die Bauteile noch eine Ahnung davon ob die der ZWave-Code auch per stacked_cc eingebunden werden ,-)

Allerdings fällt mir jetzt auf das ich bei dem Design des SendStacks sowas wie CRC16 oder TRANSPORT_SERVICE auch berücksichtigen müsste und das bisher nicht getan habe... 

Gruß,
Andreas.

[rudolfkoenig]

Bei 100k Routen ist CRC16 überflüssig und verursacht unnötigen Overhead.

Meiner Ansicht nach ist der Overhead zu vernachlaessigen, und wir sollten es implementieren.
Ich habe bloss den Eindruck, dass viele Geraete CRC16 nicht unterstuetzten, ist also kein Allheitmittel.

Kann mir bitte jemand nochmal die Reihenfolge der Pack-Klassen zeigen?

[A.Harrenberg]

Hi Rudi,

hier eine kleine Grafik mit der entsprechenden Textseite. Das ganze stammt aus "sds13783-1_z-wave_transport-encapsulation_command_class_specification.pdf". Es gab irgendwo auch noch eine andere Darstellung mit einer Tabelle, die finde ich aber gerade nicht mehr.

Security-Nachrichten dürfen aber anscheinend nicht CRC16 verpackt werden.

Ich schau mal ob ich die Logik auch in den SendStack integriert bekomme...

Gruß,
Andreas.

[A.Harrenberg]

Hi,

ok, angehängt jetzt die Tabelle die ich meinte, die ist aber "veraltet", da fehlt der Level mit der neuen Klasse "SUPERVISION".

Gruß,
Andreas.

[krikan]

Andere Übersicht in http://zwavepublic.com/sites/default/files/SDS12657-12%20-%20Z-Wave%20Command%20Class%20Specification%20A-M.pdf unter "3.8
Encapsulation order overview" (PDF-Seite 39ff.) mit Erläuterung.

Security-Nachrichten dürfen aber anscheinend nicht CRC16 verpackt werden.

wird dort auch bestätigt.

[krikan]

da fehlt der Level mit der neuen Klasse "SUPERVISION".

Geräte scheint es dazu aber noch nicht zu geben; genau wie bei SECURITY V2.