Fibaro Wall Plug FGWPF-102 Erfahrung / Genauigkeit Leistungsmessung /

Begonnen von Flachzange, 12 Januar 2025, 20:25:51

Vorheriges Thema - Nächstes Thema

Flachzange

Hallo zusammen,

vor einer Weile habe ich mein spärliches Zwave-Netz (bisher nur Fibaro Rauch- und Co-Melder), um Fibaro Wall Plugs ergänzt, um ein vernünftiges Mesh aufzubauen. Vor allem, weil der Controller in den Keller gewandert ist und somit nicht mehr alle Geräte direkt erreichen konnte.

Zum Einsatz kommen Zwave-Plus-Stecker vom Typ Fibaro FGWPF-102. Das Ziel eines vermaschten Netzes erreiche ich damit. Jetzt habe ich mir gedacht, dass ich die Stecker auch für die Leistungsmessung von Waschmaschine und Co. einsetzen kann, wenn ich sie schon habe. Dabei mache ich folgenden Beobachtung:

1) Bei eingeschalteter Messung wird mein parallel laufendes und strikt überwachtes EnOcean-Netz gestört, d.h. es gibt Kollisionen auf dem Funkmedium und EnOcean-Telegramme gehen verloren. Das hatte ich hier schon mal beschrieben.

2) Die Messdaten der Zwischenstecker sind mittelschwerer Blödsinn. Bei meiner Waschmaschine werden bis zu 3000.0 W ausgegeben (auffälligerweise genau 3000.00, die Stecker sind nur bis max 2500 ausgelegt). Nominell ist die Maschine mit 2000 W spezifziert. Mit einem old school Conrad-Gerät nachgemessen, komme ich auf 2200 W peak. Das ist leider way off.


Es sind folgende Geräte:
ZitatModel:
FIBARO System FGWPE/F Wall Plug Gen5

Version:
Lib 3 Prot 4.05 App 3.2 HW 2 FWCounter 1 FW 3.2


Sind das jetzt irgendwie spezifische Probleme, die nur ich habe und falls ja, habt Ihr Ideen, was die Ursache sein könnte?

Gibt es Alternativen zu den Fibaro-Steckern?

Danke und Gruß
Chris

rudolfkoenig

ZitatSind das jetzt irgendwie spezifische Probleme, die nur ich habe und falls ja, habt Ihr Ideen, was die Ursache sein könnte?
Ursache duerfte das zu lange Belegen des Funkraums sein.
In diesem Kontext waeren mehr Details interesant:
- das timeToAck Reading aller Geraete. Werte ueber 0.02 weisen auf indirekte (d.h. Mesh-only) oder schlechte Erreichbarkeit
- nach Setzen der generateRouteInfoEvents Attributes (https://fhem.de/commandref_modular.html#ZWave-attr-generateRouteInfoEvents) die generierten Events protokollieren.

Wegen Falschmeldungen:
- ZWave kommuniziert mit den Datenraten 9.6, 40 und 100 kBps.
- bei 100 kBps werden 2 Byte Checksums verwendet, sonst 1 Byte.
- bei 1-Byte Checksum kommt es insb. bei schlechten Bedingungen oefters zu Bitfehler, und damit unsinnigen Werten
- bei schlechten Empfang wird von 100kBps automatisch auf 40 oder gar 9.6kBps zurueckgeschaltet
- etliche Geraete implementieren die CRC_16_ENCAP Klasse, womit Nachrichten mit zusaetzlichen 2-Byte Checksum gesichert werden. Um das zu nutzen, muss man in FHEM das Attribut useCRC16 setzen: https://fhem.de/commandref_modular.html#ZWave-attr-useCRC16 

ZitatGibt es Alternativen zu den Fibaro-Steckern?
Auf die schnelle habe ich welche von Aeotec und Devolo gesehen.

Flachzange

Danke für die Hilfe!

Zitat von: rudolfkoenig am 13 Januar 2025, 10:27:25Ursache duerfte das zu lange Belegen des Funkraums sein.
In diesem Kontext waeren mehr Details interesant:
- das timeToAck Reading aller Geraete. Werte ueber 0.02 weisen auf indirekte (d.h. Mesh-only) oder schlechte Erreichbarkeit
- nach Setzen der generateRouteInfoEvents Attributes (https://fhem.de/commandref_modular.html#ZWave-attr-generateRouteInfoEvents) die generierten Events protokollieren.
Nachdem das Reading bei mir nicht generiert wurde, habe ich mich mal mit der Firmware-Version meines UZB bechäftigt und sie dann etwas abenteurlich auf Version 2.39 anheben können. Dann klappte es auch mit dem Reading. Auch wenn der Controller angeblich vorher schon SDK-Version 6.71 hatte. Ich habe in diesem Rahmen auch festgestellt, dass ich noch einige "UNKNOWN" Devices hatte, die merkwürdigerweise nicht als failed gekennzeichnet waren. Diese habe ich entfernt.

Du darfst diesen Dateianhang nicht ansehen.

Das ist natürlich eine Momentaufnahme. Was ich manchmal beobachte ist, dass "Funkstecker_Zwave_KG_Serverschrank" ein timeToack von >0.2 hat, obwohl er direkt neben dem Controller sitzt (was man ja auch gut an der RSSI erkennen kann).

Zitat von: rudolfkoenig am 13 Januar 2025, 10:27:25Wegen Falschmeldungen:
- ZWave kommuniziert mit den Datenraten 9.6, 40 und 100 kBps.
- bei 100 kBps werden 2 Byte Checksums verwendet, sonst 1 Byte.
- bei 1-Byte Checksum kommt es insb. bei schlechten Bedingungen oefters zu Bitfehler, und damit unsinnigen Werten
- bei schlechten Empfang wird von 100kBps automatisch auf 40 oder gar 9.6kBps zurueckgeschaltet
- etliche Geraete implementieren die CRC_16_ENCAP Klasse, womit Nachrichten mit zusaetzlichen 2-Byte Checksum gesichert werden. Um das zu nutzen, muss man in FHEM das Attribut useCRC16 setzen: https://fhem.de/commandref_modular.html#ZWave-attr-useCRC16
Auch hier danke, wobei Bitfehler nicht als primäre Ursache in Frage kommen. Ich kann die falschen Messergebnisse bei gleichen "Waschgängen" reproduzieren. Ich werde das mit CRC16 dennoch mal testen.

Zitat von: rudolfkoenig am 13 Januar 2025, 10:27:25Auf die schnelle habe ich welche von Aeotec und Devolo gesehen.
Danke, ich teste mal einen anderen.

Ansonsten würde ich jetzt erstmal weiter beobachten und dann wieder berichten.

Flachzange

So, ich gebe mal ein Update hier: ich habe ziemlich schnell nach der Empfehlung oben zwei Aeotec-Funkstecker besorgt. Diese Stecker messen und reporten den korrekten Verbrauch, zumindest das, was ich als korrekt bezeichnen und erwarten würde. Bei einer eigentlich höheren Sendefrequenz der Berichte habe ich in jedem Fall weniger EnOcean-Telegrammverluste, aber ich habe sie noch. Sie sind aber vermutlich in der Praxis vernachlässigbar, da sie vergleichsweise selten auftreten. Wir reden hier über 10 Telegramme pro Tag bei je ca. 100.000 empfangenen Telegrammen an den EnOcean TCMs. Schalte ich das Reporting der Aoetec-Funkstecker ab, verliere ich kein einziges oder vielleicht mal ein Telegramm am Tag. Es ist vor allem auffällig, dass die Telegrammverluste auftreten bei Geräten, die in der Nähe der Zwave-Stecker angebracht sind. Dabei gehen Telegramme von Geräten verloren, die im Empfangsbereich von mindestens 2 EnOcean Gateways (TCMs) sind und eine sehr niedrige RSSI haben.

Ich komme also zu der Erkenntnis: Zumindest mit den Aeotec-Steckern funktioniert es wie erwartet. Dass Kollisionen auftreten muss man wohl hinnehmen. Insgesamt wird Zwave kommunikationslastiger sein und damit zwangsläufig Auswirkungen auf EnOcean haben.