SIGNALduino und ESA2000?

[daubsi]

Ich habe mir gestern zwei ESP8266 mit der Signalduino Firmware installiert und in FHEM eingebunden. Soweit geht alles, es wurden einige neue Temperatursensoren usw. gefunden.

Ich nutze seit Jahren den ELV Energiemesser ESA2000-WZ, welcher das Blinken einer LED an meinem Stromzähler zählt und entsprechend an FHEM meldet. Leider funktionierte das Ganze aus unbekannten Gründen nicht besonders gut, so dass ich dachte ich könnte vielleicht das Signal über Signalduino auffangen und über diesem Umweg dem ESA2000 Modul zur Verfügung stellen und dadurch evtl. eine stabilere Anbindung realisieren.

Ich habe gesehen, dass als "Client" ein EM1000 vorhanden ist, aber das ist soweit ich sehe, eben nicht das Gleiche wie der ESA2000-WZ.

Was müsste denn konkret gemacht werden, damit das ESA2000-WZ Modul Input von Signalduino verarbeiten kann? Vermutlich muss eine eigene Demodulation/Pattern dafür geschrieben werden? Wie müsste man dazu vorgehen? Kann dafür Code des bestehenden CUL verwendet werden?

Aktuell ist die Bindung wie folgt realisiert:

define CUL CUL /dev/ttyACM0@38400 1337
setuuid CUL 644ad309-f33f-97a9-1414-8dc7e94e3784de80
attr CUL group CUL
attr CUL model CUL
attr CUL rfmode SlowRF
attr CUL room System
define ESAx000WZ_4750 ESA2000 4750
setuuid ESAx000WZ_4750 5d2a1b6c-f33f-97a9-6bb1-1f1c3274ea844be5
attr ESAx000WZ_4750 IODev CUL
attr ESAx000WZ_4750 room Cellar

[daubsi]

Ich bin ein bisschen weiter und habe jetzt einige Versuche gemacht:

ESA2000WZ-LED klassisch via CUL_FW empfangen, parallel mit SIGNALduino (SIGNALESP auf einem Wemos D1 um genau zu sein) via IP Anbindung und dann noch mit RTL-SDR und URH und rtl_433 das Signal aufzeichnen.

Ich habe mir die culfw angesehen und verstanden wie die Funktion analyze_esp aus dem Input Buffer der empfangenen Daten die Ausgabe S... (z.B. S634750011E00134534000B159FFA01B302) generiert und konnte damit den Inputdatenstrom errechnen, der dieses Ergebnis erzeugt, d.h. den ich also irgendwie hoffentlich auch im SIGNALESP oder URH sehen müsste.

Was ich noch nicht angeschaut habe war wie die culfw den Inputdatenstrom demoduliert, bevor er an analyze_esp gegeben wird. Ich hatte gelesen, dass es sich dabei um ein Manchester codiertes Signal handeln würde, was mir SIGNALESP prinzipiell auch loggt (es kommt allerdings stark zeitversetzt im Log an?)

2024.09.09 08:28:09 4: MySignalduino_Cellar: Read, msg: MC;LL=-1044;LH=966;SL=-570;SH=438;D=AAAAAAAAAA;C=502;L=40;R=223;
2024.09.09 08:28:09 4: MySignalduino_Cellar: Read, msg: MC;LL=-1044;LH=966;SL=-570;SH=438;D=B6A1AFFFBEDB232880;C=502;L=70;R=223;
2024.09.09 08:33:35 4: MySignalduino_Cellar: Read, msg: MC;LL=-1071;LH=941;SL=-587;SH=416;D=AAAAAAAAAA;C=502;L=40;R=218;
2024.09.09 08:33:35 4: MySignalduino_Cellar: Read, msg: MC;LL=-1071;LH=941;SL=-587;SH=416;D=B6A1AFFFBEDB232880;C=502;L=70;R=218;
2024.09.09 08:54:14 4: MySignalduino_Cellar: Read, msg: MC;LL=-1044;LH=967;SL=-525;SH=488;D=AAAAAAAAAA;C=503;L=40;R=221;
2024.09.09 08:54:14 4: MySignalduino_Cellar: Read, msg: MC;LL=-1044;LH=967;SL=-525;SH=488;D=B6A1AFFE3ED8E32EBC;C=503;L=70;R=221;

Diese Meldungen scheinen prinzipiell zu passen, denn es sind auch das was ich im URH zeitgleich auffange, wenn die LED des ESA2000WZ-LED blinkt.

Du darfst diesen Dateianhang nicht ansehen.
(Das hier gezeigte Signal ist nicht 100% das was ich oben im Logausschnitt gepastet habe)

Basierend auf diversen Schnippsel aus dem Internet habe ich ermittelt, dass es sich bei dem Signal um ein Manchester codiertes Signal mit den gezeigten Pulslängen handelt. Ich vermute das aaaaaa Prefix dürfte eine gängige Preample sein. Das Problem ist, dass wenn ich das im Screenshot gezeigte Signal im "Analysis" Tab mit MC decodieren möchte sind Decodierungs-Fehler enthalten und ganz generell deckt sich keiner meiner Decodierungsversuche bislang mit dem was ich initial als "Sollinput" zur Erzeugung des S.....Ausgabestrings ermittelt habe.

Hat sich jemand schon mal mit dem konkreten Format der ESA2000WZ-LED befasst und kann mir mehr dazu sagen?

[daubsi]

rtl_433 liefert mir z.B. folgende Analyse (Slicer ggf. manuell auf MC umstellen, was schon sehr brauchbar aussieht

https://triq.org/pdv/#AAB104FFFF00F801F8FFFF8191919191919191919191919191929191A291A19291919191A192A2A192919191A192919191A291A2A192A192A192A192A2A19192A192A291A29191A1929191A191929191A2919191919191A192A29191A291A19291A291A192919191A291A2919191A2A192A2A2A291A19291A1919192A192A1919291A2A355

[daubsi]

Oookay, Fortschritt!

Nehme ich den triq.org Link von oben und kopiere mir das MC decodierte heraus:

Bits: {184} 00 / FF FE 26 0D 61 84 B6 DA ED 23 1C 40 68 99 30 90 B5 4C F6 E5

Nehme die Bytes nach 0xfffe (-> 0x260d61...)
und lasse das mittels analyze_esa() drüber laufen:

Errechnet meine angepasste Routine:

data[3] = 0x84 -> 0x01
data[4] = 0xb6 -> 0x1e
data[5] = 0xda -> 0x00
data[6] = 0xed -> 0x13
data[7] = 0x23 -> 0x32
data[8] = 0x1c -> 0x5b
data[9] = 0x40 -> 0x00
data[10] = 0x68 -> 0x0c
data[11] = 0x99 -> 0x15
data[12] = 0x30 -> 0x8d
data[13] = 0x90 -> 0xc4
data[14] = 0xb5 -> 0x01
Success!
SAF4750011E0013325B000C158DC401B30000

Real reference string:
S634750011E00134534000B159FFA01B302

Und da ist doch eine sehr schöne Übereinstimmung sichtbar! :-D

Gehe ich also nun nochmal nach URH->Analysis und selektiere den 1. und 3. Stream aus dem Capture und decodiere mit "Manchester II" bekomme ich auch diesen Stream - allerdings eben mit Decodierungs-Fehlern:

Du darfst diesen Dateianhang nicht ansehen.

Aber wie kriege ich SIGNALduino dazu, auch diese Art von Decodierung zu machen? Das was hier geloggt wird ist in Summe ja viel zu kurz :-/ 

2024.09.09 09:09:53 4: MySignalduino_Cellar: Read, msg: MC;LL=-1038;LH=986;SL=-506;SH=498;D=AAAAAAAAAA;C=504;L=40;R=224;
2024.09.09 09:09:53 4: MySignalduino_Cellar: Read, msg: MC;LL=-1038;LH=986;SL=-506;SH=498;D=B6A1AFFF3FDEE32AD8;C=504;L=70;R=224;
2024.09.09 09:15:07 4: MySignalduino_Cellar: Read, msg: MC;LL=-1031;LH=984;SL=-536;SH=462;D=AAAAAAAAAA;C=502;L=40;R=224;
2024.09.09 09:15:07 4: MySignalduino_Cellar: Read, msg: MC;LL=-1031;LH=984;SL=-536;SH=462;D=B6A1AFFEBFDF60;C=502;L=54;R=224;
2024.09.09 09:20:19 4: MySignalduino_Cellar: Read, msg: MC;LL=-1029;LH=980;SL=-522;SH=503;D=AAAAAAAAAA;C=505;L=40;R=224;
2024.09.09 09:20:19 4: MySignalduino_Cellar: Read, msg: MC;LL=-1029;LH=980;SL=-522;SH=503;D=B6A1AFFEBFDFBD2B4C;C=505;L=70;R=224;

[daubsi]

Verwende ich den fffe97... String aus URH, beginne mit 0x97fc und jage den durch meine Routine, schlägt wie erwartet die Checksum fehl - er hat ja auch MC Decodierungsfehler gehabt... aber die grundsätzliche Struktur ist wieder vorhanden:

ata[0] = 0x97 -> 0x1e
data[1] = 0xfc -> 0x47
data[2] = 0x70 -> 0x50
data[3] = 0x95 -> 0x01
data[4] = 0xa7 -> 0x1e
data[5] = 0xcb -> 0x00
data[6] = 0xfc -> 0x13
data[7] = 0x68 -> 0x48
data[8] = 0x9e -> 0x12
data[9] = 0xc2 -> 0x00
data[10] = 0xf6 -> 0x10
data[11] = 0x0f -> 0x15
data[12] = 0x90 -> 0xa3
data[13] = 0xc5 -> 0x71
data[14] = 0xe8 -> 0x01

Checksum fail )
S1E4750011E00134812001015A37101B30000
Reference:
S634750011E00134534000B159FFA01B302

[daubsi]

Du darfst diesen Dateianhang nicht ansehen.

Ich hab mal den Mitschnitt von URH eingefügt. Hier sieht man schön die beiden empfangenen Nachrichten.

Was ist zu tun, damit der MC Decoder in SIGNALduino das so parst wie es auch rtl_433 macht und zu diesem Ergebnis kommt? (Wenn man auf der Webseite auf MC umstellt)

https://triq.org/pdv/#AAB104FFFF00F801F8FFFF8191919191919191919191919191929191A291A19291919191A192A2A192919191A192919191A291A2A192A192A192A192A2A19192A192A291A29191A1929191A191929191A2919191919191A192A29191A291A19291A291A192919191A291A2919191A2A192A2A2A291A19291A1919192A192A1919291A2A355