Closed duko1234 closed 1 year ago
Can we speak German?
Ich habe einen neuen Branch erstellt. Ein Update darauf kannst du mit folgendem Befehl auslösen:
update all https://raw.githubusercontent.com/RFD-FHEM/RFFHEM/master_ade-ws1907/controls_signalduino.txt
Damit sollte der Empfang funktionieren.
@elektron-bbs
Für mich sieht es so aus, als ob der Puffer überläuft und die Wiederholung nicht vollständig enthalten ist. Der Teil vor der Wiederholung ist halt leider ungünstig, da das lange Aufwachsignal am Anfang variabel ist.
@elektron-bbs Für mich sieht es so aus, als ob der Puffer überläuft und die Wiederholung nicht vollständig enthalten ist.
Genau so ist es.
Der Teil vor der Wiederholung ist halt leider ungünstig, da das lange Aufwachsignal am Anfang variabel ist.
Naja, es werden aber jetzt seine Msg und auch die aus dem damaligen Issue https://github.com/RFD-FHEM/RFFHEM/issues/965 dekodiert. Für die Verarbeitungszeit ist es sicher ungünstiger wegen fehlendem start.
Ich glaube eher die Wiederholung ist nicht vollständig, da sie kürzer ist, als der Teil vom 1. Aufwachen bis zu dem +7000 Signal.
Erstmal vielen Dank für die schnellen Antworten. Ich habe deinen Branch gezogen. Das hat leider nicht zum Erfolg geführt. Der Sensor wird immernoch nicht erstellt.
Hier nochmal das neue Log:
21:20:32 1.8mm
2023.01.09 21:20:31 4: sduino: Read, msg READredu: MU;P0=1384;P1=-2667;P2=989;P3=-961;P4=2702;P5=7364;D=01212343412341212123434343434343434341234343412121234123412123434343434343434341234123434341234343434341212343412341212123434341534341212343412341212123434343434343434341234343412121234123412123434343434343434341234123434341234343434341212343412341212123;CP=2;R=243;O;
2023.01.09 21:20:32 4: sduino: Read, msg READredu: MU;P0=2696;P1=-957;P2=-2662;P3=7348;P4=1001;P5=1888;P6=-18908;D=010102310102424101024102424241010101010101010102410101024242410241024241010101010101010102410241010102410101010102424101024102424241010101010101010156;CP=0;R=243;
21:21:16 1.8mm
2023.01.09 21:21:16 4: sduino: Read, msg READredu: MU;P0=200;P1=-959;P2=2702;P3=-2664;P4=992;P5=7364;D=01212343412123412343434121212121212121212341234123434343412343434121212121212121212341234121212341212121212343412123434123412341212351212343412123412343434121212121212121212341234123434343412343434121212121212121212341234121212341212121212343412123434123;CP=4;R=245;O;
2023.01.09 21:21:17 4: sduino: Read, msg READredu: MU;P0=989;P1=-954;P2=2703;P3=-2661;P4=7348;P5=1980;P6=-21576;D=0123012123412123030121230123030301212121212121212123012301230303030123030301212121212121212123012301212123012121212123030121230301230123012121212121212156;CP=2;R=246;
21:22:02 1.8mm
2023.01.09 21:22:01 4: sduino: Read, msg READredu: MU;P0=-176;P1=1316;P2=-957;P3=2704;P4=-2663;P5=999;P6=7324;D=01232345452323452345454523232323232323232345452323232323232345454523232323232323452345234523232345232323232345452323454545454523452346232345452323452345454523232323232323232345452323232323232345454523232323232323452345234523232345232323232345452323454545;CP=3;R=242;O;
2023.01.09 21:22:02 4: sduino: Read, msg READredu: MU;P0=-2664;P1=995;P2=-958;P3=2702;P4=7348;P5=1900;P6=-15892;D=01012301230423230101232301230101012323232323232323230101232323232323230101012323232323232301230123012323230123232323230101232301010101012301232323232323256;CP=3;R=242;
21:23:31 1.8mm
2023.01.09 21:23:31 4: sduino: Read, msg READredu: MU;P0=-224;P1=7282;P2=-928;P3=2727;P4=-2645;P5=1025;D=01232345452323452345454523232323232323232323232323232323454523452323232323232323452345234523234523232323232345452345232323234523452341232345452323452345454523232323232323232323232323232323454523452323232323232323452345234523234523232323232345452345232323;CP=3;R=234;O;
2023.01.09 21:23:32 4: sduino: Read, msg READredu: MU;P0=-1028;P1=2711;P2=-2630;P3=1015;P4=7392;P5=1896;P6=-7508;P7=112;D=0123012301240101232301012301232323010101010101010101010101010101012323012301010101010101012301230123010123010101010101232301230101010123012301010101010105670;CP=1;R=234;
Hast du FHEM neu gestartet?
@duko1234 Welchen Microcontroller verwendest Du?
Hast du FHEM neu gestartet?
Ja und versionmodule zeigt 3.5.5+20230107
@duko1234 Welchen Microcontroller verwendest Du?
Lauft Verkäufer: MINI-USB Nano V3.0 ATMEGA328P FT232RL FTDI mit Active-, TX- und RX-LED
@elektron-bbs
Ich denke das wäre eine vollständige Nachricht:
23234545232345234545452323232323232323232323232323232345452345232323232323232345234523452323452323232323234545234523232323452345234
Ich habe gerade nochmal mein gesamtes FHEM.log durchsucht und ich habe tatsächlich zwei Log-Einträge gefunden, bei denen ein ADE WS1907 gematched wurde. Ich nehme an, das Device wurde nicht erzeugt, weil die Nachrichten nicht oft genug kamen?
2023.01.08 07:32:49 4: sduino: Read, msg READredu: MU;P0=975;P1=-973;P2=2681;P3=92;P5=-602;P6=7058;P7=-2689;D=53567070121212127070701212707012121212121212127012127012701270701270121212121212121212701212707012701212121212707012127012707070707012767070121212127070701212707012121212121212127012127012701270701270121212121212121212701212707012701212121212707012127012;CP=0;R=47;O;
2023.01.08 07:32:49 4: sduino: Parse_MU, Fingerprint for MU protocol id 110 -> ADE_WS_1907 matches, trying to demodulate
2023.01.08 07:32:49 4: sduino: Parse_MU, last part pair=7 reconstructed, bit=1
2023.01.08 07:32:49 4: sduino: Parse_MU, Decoded matched MU protocol id 110 dmsg W110#C39804AD004D065F4 length 68 dispatch(1/4) RSSI = -50.5
2023.01.08 20:11:00 4: sduino: Read, msg READredu: MU;P1=584;P2=228;P3=-112;P5=-7907;P6=-4067;P7=-1841;D=15161717161716161717171617171717171716171617161717171616171617171617161723;CP=1;R=243;
2023.01.08 20:11:03 4: sduino: Read, msg READredu: MU;P0=982;P1=-966;P2=2698;P4=92;P5=-476;P6=7052;P7=-2679;D=45670701212121270707012127070121212121212127012701270127012707012701212121212121212127012701270127012121212127070121270701270701270127670701212121270707012127070121212121212127012701270127012707012701212121212121212127012701270127012121212127070121270701;CP=0;R=49;O;
2023.01.08 20:11:03 4: sduino: Parse_MU, Fingerprint for MU protocol id 110 -> ADE_WS_1907 matches, trying to demodulate
2023.01.08 20:11:03 4: sduino: Parse_MU, last part pair=7 reconstructed, bit=1
2023.01.08 20:11:03 4: sduino: Parse_MU, Decoded matched MU protocol id 110 dmsg W110#C3980AAD0055066D4 length 68 dispatch(1/4) RSSI = -49.5
Das kam gestern 2x vor, danach nie wieder.
Ich habe jetzt mal nur diese probiert:
MU;P0=200;P1=-959;P2=2702;P3=-2664;P4=992;P5=7364;D=01212343412123412343434121212121212121212341234123434343412343434121212121212121212341234121212341212121212343412123434123412341212351212343412123412343434121212121212121212341234123434343412343434121212121212121212341234121212341212121212343412123434123;CP=4;R=245;O;
ergibt hier:
Internals:
CFGFN
CODE [SD_WS_110_TR](http://raspberrypi3:8083/fhem?detail=SD_WS_110_TR)
DEF [SD_WS_110_TR](http://raspberrypi3:8083/fhem?detail=SD_WS_110_TR)
FUUID 63bc484d-f33f-9025-50af-160fdff4257adec2
LASTInputDev [sduino_dummy](http://raspberrypi3:8083/fhem?detail=sduino_dummy)
MSGCNT 10
NAME [SD_WS_110_TR](http://raspberrypi3:8083/fhem?detail=SD_WS_110_TR)
NR 540
STATE T: 22.1 R: 25.7
TYPE SD_WS
bitMSG 00110010111000000000101011110111000000000101000100000110011010100100
eventCount 10
lastMSG 32E00AF70051066A4
lastReceive 1673296492.40144
sduino_dummy_DMSG W110#32E00AF70051066A4
sduino_dummy_MSGCNT 10
sduino_dummy_Protocol_ID 110
sduino_dummy_RAWMSG MU;P0=200;P1=-959;P2=2702;P3=-2664;P4=992;P5=7364;D=01212343412123412343434121212121212121212341234123434343412343434121212121212121212341234121212341212121212343412123434123412341212351212343412123412343434121212121212121212341234123434343412343434121212121212121212341234121212341212121212343412123434123;CP=4;R=245;O;
sduino_dummy_RSSI -79.5
sduino_dummy_TIME 2023-01-09 21:34:52
Helper:
DBLOG:
RSSI:
[myDbLog](http://raspberrypi3:8083/fhem?detail=myDbLog):
TIME 1673296492.40842
VALUE -79.5
temperature:
[myDbLog](http://raspberrypi3:8083/fhem?detail=myDbLog):
TIME 1673296492.40842
VALUE 22.1
RXMIT_TIME:
1673296492.4015
READINGS:
2023-01-09 21:34:52 MSGCNTLAST10MIN 0
2023-01-09 18:01:33 batteryChanged 0
2023-01-09 21:34:52 batteryState ok
2023-01-09 21:34:52 model [SD_WS_110_TR](http://raspberrypi3:8083/fhem?detail=SD_WS_110_TR)
2023-01-09 21:34:52 rain 25.7
2023-01-09 21:34:52 rawRainCounter 257
2023-01-09 21:34:52 sendCounter 5
2023-01-09 21:34:52 state T: 22.1 R: 25.7
2023-01-09 21:34:52 temperature 22.1
2023-01-09 18:01:33 type ADE WS1907
Attributes:
event-min-interval .*:300
event-on-change-reading .*
room Test
Das heißt, du kannst eine meiner Nachrichten einfach dekodieren und es funktioniert alles? Wie hast du die Nachricht von mir "ausgewertet"?
Ich hatte aktuell nur das 110er Protokoll aktiv. Habe jetzt nochmal alle aktiviert. Das Log bei einer Nachricht sieht dann so aus:
2023.01.09 22:32:32 4: sduino: Read, msg READredu: MU;P0=-943;P1=156;P2=-224;P3=7098;P4=-2656;P5=1004;P7=2719;D=01234507454507450707454507454507074507070707070707070745450707450707070707070707070707454545074545070707070707454507074545074545074507434507454507450707454507454507074507070707070707070745450707450707070707070707070707454545074545070707070707454507074545;CP=5;R=235;O;
2023.01.09 22:32:32 4: sduino: Parse_MU, Fingerprint for MU protocol id 49.2 -> GT-9000 matches, trying to demodulate
2023.01.09 22:32:32 4: sduino: Parse_MU, Fingerprint for MU protocol id 61 -> FS10 matches, trying to demodulate
2023.01.09 22:32:32 4: sduino: Parse_MU, Fingerprint for MU protocol id 70 -> FHT80TF matches, trying to demodulate
2023.01.09 22:32:32 4: sduino: Parse_MU, Fingerprint for MU protocol id 73 -> FHT80 matches, trying to demodulate
2023.01.09 22:32:32 4: sduino: Parse_MU, Fingerprint for MU protocol id 74 -> FS20 matches, trying to demodulate
2023.01.09 22:32:32 4: sduino: Parse_MU, Fingerprint for MU protocol id 80 -> EM1000WZ matches, trying to demodulate
2023.01.09 22:32:32 4: sduino: Read, msg READredu: MU;P0=-941;P1=2717;P2=-2643;P3=1019;P4=7360;P5=288;P6=-9980;D=0123230123012423012323012301012323012323010123010101010101010101232301012301010101010101010101012323230123230101010101012323010123230123230123012323232323256;CP=3;R=235;
Stoppt der dann nach Protokoll 80 oder wie ist das zu interpretieren? Er schreibt ja auch bei allen, die er getestet hat, dass sie matchen...
Die meisten Nachrichten (ich habe nicht alle probiert) werden hier anstandslos dekodiert. Ich lade mal meine Excel-Tabelle mit hoch. Auf Blatt 3 sind die Daten deiner Nachrichten. Außerdem schicke ich noch eine Textdatei mit meinen Aufzeichnungen der Tests. ADE_WS1907_01.xlsx ADE_WS1907_rain-gauge.txt
Zum Testen verwende ich hier das SIGNALduino_TOOL (https://github.com/RFD-FHEM/SIGNALduino_TOOL). Du kannst auch Nachrichten so dispatchen:
get sduino rawmsg MU;;P0=-943;;P1=156;;P2=-224;;P3=7098;;P4=-2656;;P5=1004;;P7=2719;;D=01234507454507450707454507454507074507070707070707070745450707450707070707070707070707454545074545070707070707454507074545074545074507434507454507450707454507454507074507070707070707070745450707450707070707070707070707454545074545070707070707454507074545;;CP=5;;R=235;;O;;
oder halt über die Oberfläche von FHEM, bei deinem SIGNALduino mittels Button get rawmsg.
Was mich stutzig macht, ist, das bei dir vollkommen andere Protokolle matchen als hier. Das ist die Nachricht von gestern Abend 22:32 Uhr:
2023.01.09 22:32:32 4: sduino: Read, msg READredu: MU;P0=-943;P1=156;P2=-224;P3=7098;P4=-2656;P5=1004;P7=2719;D=01234507454507450707454507454507074507070707070707070745450707450707070707070707070707454545074545070707070707454507074545074545074507434507454507450707454507454507074507070707070707070745450707450707070707070707070707454545074545070707070707454507074545;CP=5;R=235;O;
2023.01.09 22:32:32 4: sduino: Parse_MU, Fingerprint for MU protocol id 49.2 -> GT-9000 matches, trying to demodulate
2023.01.09 22:32:32 4: sduino: Parse_MU, Fingerprint for MU protocol id 61 -> FS10 matches, trying to demodulate
2023.01.09 22:32:32 4: sduino: Parse_MU, Fingerprint for MU protocol id 70 -> FHT80TF matches, trying to demodulate
2023.01.09 22:32:32 4: sduino: Parse_MU, Fingerprint for MU protocol id 73 -> FHT80 matches, trying to demodulate
2023.01.09 22:32:32 4: sduino: Parse_MU, Fingerprint for MU protocol id 74 -> FS20 matches, trying to demodulate
2023.01.09 22:32:32 4: sduino: Parse_MU, Fingerprint for MU protocol id 80 -> EM1000WZ matches, trying to demodulate
----------------------------- hier ohne update:
2023.01.10 08:33:02.034 4: sduino_dummy: get rawmsg: MU;P0=-943;P1=156;P2=-224;P3=7098;P4=-2656;P5=1004;P7=2719;D=01234507454507450707454507454507074507070707070707070745450707450707070707070707070707454545074545070707070707454507074545074545074507434507454507450707454507454507074507070707070707070745450707450707070707070707070707454545074545070707070707454507074545;CP=5;R=235;O;
2023.01.10 08:33:02.071 4: sduino_dummy: Parse_MU, Fingerprint for MU protocol id 28 -> IC Ledspot matches, trying to demodulate
2023.01.10 08:33:02.114 4: sduino_dummy: Parse_MU, Fingerprint for MU protocol id 50 -> Opus_XT300 matches, trying to demodulate
2023.01.10 08:33:02.122 4: sduino_dummy: Parse_MU, Fingerprint for MU protocol id 64 -> WH2 matches, trying to demodulate
2023.01.10 08:33:02.129 4: sduino_dummy: Parse_MU, Fingerprint for MU protocol id 70 -> FHT80TF matches, trying to demodulate
2023.01.10 08:33:02.134 4: sduino_dummy: Parse_MU, Fingerprint for MU protocol id 73 -> FHT80 matches, trying to demodulate
2023.01.10 08:33:02.138 4: sduino_dummy: Parse_MU, Fingerprint for MU protocol id 74 -> FS20 matches, trying to demodulate
2023.01.10 08:33:02.170 4: sduino_dummy: Parse_MU, Fingerprint for MU protocol id 110 -> ADE_WS_1907 matches, trying to demodulate
2023.01.10 08:33:02.175 4: sduino_dummy: Parse_MU, last part pair=4 reconstructed, bit=1
2023.01.10 08:33:02.179 4: sduino_dummy: Parse_MU, Decoded matched MU protocol id 110 dmsg W110#B4D900640076066D4 length 68 dispatch(1/4) RSSI = -84.5
2023.01.10 08:33:02.186 4: sduino_dummy: SD_WS_Parse protocol 110, rawData B4D900640076066D4
2023.01.10 08:33:02.187 4: sduino_dummy: SD_WS_Parse decoded protocol-id 110 (ADE WS1907), sensor-id B4D9
2023.01.10 08:33:02.187 1: sduino_dummy: SD_WS_Parse UNDEFINED sensor SD_WS_110_TR detected, code SD_WS_110_TR
----------------------------- hier nach update all https://raw.githubusercontent.com/RFD-FHEM/RFFHEM/master_ade-ws1907/controls_signalduino.txt:
2023.01.10 10:01:43.974 4: sduino_dummy: get rawmsg: MU;P0=-943;P1=156;P2=-224;P3=7098;P4=-2656;P5=1004;P7=2719;D=01234507454507450707454507454507074507070707070707070745450707450707070707070707070707454545074545070707070707454507074545074545074507434507454507450707454507454507074507070707070707070745450707450707070707070707070707454545074545070707070707454507074545;CP=5;R=235;O;
2023.01.10 10:01:44.011 4: sduino_dummy: Parse_MU, Fingerprint for MU protocol id 28 -> IC Ledspot matches, trying to demodulate
2023.01.10 10:01:44.054 4: sduino_dummy: Parse_MU, Fingerprint for MU protocol id 50 -> Opus_XT300 matches, trying to demodulate
2023.01.10 10:01:44.062 4: sduino_dummy: Parse_MU, Fingerprint for MU protocol id 64 -> WH2 matches, trying to demodulate
2023.01.10 10:01:44.069 4: sduino_dummy: Parse_MU, Fingerprint for MU protocol id 70 -> FHT80TF matches, trying to demodulate
2023.01.10 10:01:44.075 4: sduino_dummy: Parse_MU, Fingerprint for MU protocol id 73 -> FHT80 matches, trying to demodulate
2023.01.10 10:01:44.078 4: sduino_dummy: Parse_MU, Fingerprint for MU protocol id 74 -> FS20 matches, trying to demodulate
2023.01.10 10:01:44.111 4: sduino_dummy: Parse_MU, Fingerprint for MU protocol id 110 -> ADE_WS_1907 matches, trying to demodulate
2023.01.10 10:01:44.116 4: sduino_dummy: Parse_MU, last part pair=4 reconstructed, bit=1
2023.01.10 10:01:44.120 4: sduino_dummy: Parse_MU, Decoded matched MU protocol id 110 dmsg W110#B4D900640076066D4 length 68 dispatch(1/4) RSSI = -84.5
2023.01.10 10:01:44.127 4: sduino_dummy: SD_WS_Parse protocol 110, rawData B4D900640076066D4
2023.01.10 10:01:44.128 4: sduino_dummy: SD_WS_Parse decoded protocol-id 110 (ADE WS1907), sensor-id B4D9
-------------------------------------------------------------------------------------------------------------------------------------------------
@sidey79 Hast du eine Erklärung dafür? Ich weiß nicht, welche Bedingungen passen müssen, das diese Logausgabe erzeugt wird. Es scheint ja fast so, als ob unterschiedlich gerechnet wird. Wir hatten schon mal einen ähnlichen Effekt, als irgend jemand eine andere round-Routine eingebaut hatte.
oder halt über die Oberfläche von FHEM, bei deinem SIGNALduino mittels Button get rawmsg.
Mit getRawMsg sagt er mir ebenfalls, dass er die Nachricht nicht matchen kann.
Komisch ist auch noch, dass er andere WS Protokolle problemlos matcht. Ich habe diverse ID 58 Sensoren bei mir in FHEM, die wohl in der Nachbarschaft stehen. Auch noch irgendeinen Auriol.
Es scheint ja fast so, als ob unterschiedlich gerechnet wird. Wir hatten schon mal einen ähnlichen Effekt, als irgend jemand eine andere round-Routine eingebaut hatte.
In der Richtung habe ich eig. nichts gemacht. Müsste sowas dann nicht auch auf die anderen Protokolle durchschlagen?
Mit getRawMsg sagt er mir ebenfalls, dass er die Nachricht nicht matchen kann.
Bekommst du dabei immer noch die Matches wie gestern?
id 49.2 -> GT-9000
id 61 -> FS10
70 -> FHT80TF
id 73 -> FHT80
id 74 -> FS20
id 80 -> EM1000WZ
@duko1234
Ich bräuchte ein list vom Signalduino und ein Dispatchen der Nachricht bei aktiviertem Debug Attribut.
Das Debug dann wieder ausschalten, da so sehr viele Nachrichten im Log landen.
Auf welchem System lässt Du FHEM laufen und welchen Versionstand hat es. Am besten mal ein Version in FHEM absetzen.
Mit getRawMsg sagt er mir ebenfalls, dass er die Nachricht nicht matchen kann.
Bekommst du dabei immer noch die Matches wie gestern?
id 49.2 -> GT-9000 id 61 -> FS10 70 -> FHT80TF id 73 -> FHT80 id 74 -> FS20 id 80 -> EM1000WZ
Das hier hab ich dann im Log bekommen:
2023.01.10 23:25:53 4: sduino: get rawmsg: MU;P0=-943;P1=156;P2=-224;P3=7098;P4=-2656;P5=1004;P7=2719;D=01234507454507450707454507454507074507070707070707070745450707450707070707070707070707454545074545070707070707454507074545074545074507434507454507450707454507454507074507070707070707070745450707450707070707070707070707454545074545070707070707454507074545;CP=5;R=235;O;
2023.01.10 23:25:53 4: sduino: Parse_MU, Fingerprint for MU protocol id 61 -> FS10 matches, trying to demodulate
2023.01.10 23:25:53 4: sduino: Parse_MU, Fingerprint for MU protocol id 80 -> EM1000WZ matches, trying to demodulate
2023.01.10 23:26:05 4: sduino: Read, msg READredu: MU;P0=-4069;P1=-1852;P2=-1068;P4=595;P5=965;P7=-7864;D=24252525247404141404140404141404140414141414140414041414041414140404041414141404041414141404;CP=4;R=236;
2023.01.10 23:26:05 4: sduino: Read, msg READredu: MU;P0=-10984;P1=123;P2=-1851;P3=971;P4=-1008;P5=610;P6=-7896;P7=-4058;D=1234343434565752525752575752525752575252525252575257525257525252575757525252525757525252525750141;CP=5;R=236;
Ich bräuchte ein list vom Signalduino und ein Dispatchen der Nachricht bei aktiviertem Debug Attribut.
Hier die Ausgabe von list und das log mit aktiviertem Debug: list.txt log.txt
Auf welchem System lässt Du FHEM laufen und welchen Versionstand hat es. Am besten mal ein Version in FHEM absetzen.
Hier die Ausgabe von version: version.txt
Besten Dank euch!
@duko1234 @elektron-bbs
Also es liegt an der Round Funktionalität. Da bin ich mir recht sicher. Irgendwas überschreibt in der Symboltabelle vermutlich die round funktion. Könnte POSIX sein oder auch jedes andere beliebige Modul. Du könntest ja mal nach POSIX oder round bei deinem FHEM lokal suchen.
Wenn das so ist, dann ist es wieder einmal ein nettes Beispiel, wieso es nicht gut ist seine Funktionen in main zu packen.
Ich habe zwar auch diese Vermutung, aber es wundert mich, das bei ihm falsche Pattern erscheinen:
2023.01.10 23:41:10 4: sduino: get rawmsg: MU;P0=-943;P1=156;P2=-224;P3=7098;P4=-2656;P5=1004;P7=2719;D=01234507454507450707454507454507074507070707070707070745450707450707070707070707070707454545074545070707070707454507074545074545074507434507454507450707454507454507074507070707070707070745450707450707070707070707070707454545074545070707070707454507074545;CP=5;R=235;O;
2023.01.10 23:41:11 1: DEBUG>Testing against protocol id 110 -> ADE_WS_1907
2023.01.10 23:41:11 1: DEBUG>Searching in patternList: $VAR1 = {
'-3' => '1',
'0' => '-1',
'1' => undef,
'2' => '0',
'3' => '1',
'5' => '1',
'8' => '1'
};
So sieht es auf einem "gesunden" System aus:
2023.01.11 11:17:17.153 1: DEBUG>Testing against protocol id 110 -> ADE_WS_1907
2023.01.11 11:17:17.154 1: DEBUG>Searching in patternList: $VAR1 = {
'5' => '1.1',
'3' => '7.9',
'1' => '0.2',
'0' => '-1.0',
'4' => '-3.0',
'2' => '-0.2',
'7' => '3.0'
};
Ja das hat mich auch gewundert. Liegt aber vielleicht an der Rückgabe von round.
Oder die Platten stimmen vorher schon nicht, allerdings werden sie ja richtig ausgegeben im Log.
Um das zu verifizieren, müsste man probehalber eine eigene round-Routine einbauen.
Oder Math::round verwenden. :)
Also es liegt an der Round Funktionalität. Da bin ich mir recht sicher. Irgendwas überschreibt in der Symboltabelle vermutlich die round funktion. Könnte POSIX sein oder auch jedes andere beliebige Modul. Du könntest ja mal nach POSIX oder round bei deinem FHEM lokal suchen.
Sorry, in welcher Datei soll ich suchen? Nach Definitionen der Round Funktion?
Oder Math::round verwenden. :)
Wo müsste man das verwenden?
Besten Dank!
Sorry, in welcher Datei soll ich suchen? Nach Definitionen der Round Funktion?
In allen Dateien im FHEM Verzeichnis. Z.B. mittels grep
Oder Math::round verwenden. :)
Wo müsste man das verwenden?
Das würde ich in das SIGNALduino Modul einbauen. Es gab allerdings einen Grund wieso das vor 7 Jahren ausgebaut wurde :)
In allen Dateien im FHEM Verzeichnis. Z.B. mittels grep
Ich habe jetzt mittels folgendem grep nach round und POSIX gesucht.
duko1234@raspberrypi:/opt/fhem $ find -type f -name '*.p[lm]' -exec grep -i -n -w -H "POSIX" "{}" ";"
duko1234@raspberrypi:/opt/fhem $ find -type f -name '*.p[lm]' -exec grep -i -n -w -H "round" "{}" ";"
Ich hoffe das hattest du im Sinn. Die Suchergebnisse habe ich mal angehängt.
Also ich habe die mal durchgesehen, mir ist aber nichts aufgefallen. Die einzige Definition von round sehe ich in 99_utils.pm.
Im Signalduino_pm ist mir aufgefallen, dass an einer Stelle main::round statt round verwendet wird. Bei POSIX sehe ich halt einfach nur tausende Einbindungen des POSIX Pakets...
Ich hoffe ich habe durch mein grep/find jetzt keine Dateien ausgeschlossen, die ich hätte eigentlich noch durchsuchen sollen.
Das würde ich in das SIGNALduino Modul einbauen. Es gab allerdings einen Grund wieso das vor 7 Jahren ausgebaut wurde :)
Ah ok.
Ich kann in den Dateien nichts auffälliges finden. In Verdacht hätte ich ja folgende drei Dateien:
No Id found for 32_EspLedController.pm !!!
99_myUtils_Astro.pm 11 2017-07-15 00:00:00Z Fhemmike !!!
No Id found for 99_TimeUtils.pm !!!
Um sicher zu gehen, das es wirklich an round liegt, habe ich mal eine eigene Routine dafür in die 00_SIGNALduino.pm eingebaut:
Ich musste die Datei umbenennen, da Github keine *.pm akzeptiert. Bitte mal damit probieren. Es sind auch noch vier zusätzliche Debug-Ausgaben darin.
Um sicher zu gehen, das es wirklich an round liegt, habe ich mal eine eigene Routine dafür in die 00_SIGNALduino.pm eingebaut:
Ich musste die Datei umbenennen, da Github keine *.pm akzeptiert. Bitte mal damit probieren. Es sind auch noch vier zusätzliche Debug-Ausgaben darin.
Hab die Datei ausgetauscht und neu gestartet. Das Device wurde direkt nach 3 Messages angelegt. Habe hier nochmal das Log seit dem Neustart:
Damit ist jetzt wohl sicher, dass es round ist...
Ich kann in den Dateien nichts auffälliges finden. In Verdacht hätte ich ja folgende drei Dateien:
No Id found for 32_EspLedController.pm !!! 99_myUtils_Astro.pm 11 2017-07-15 00:00:00Z Fhemmike !!! No Id found for 99_TimeUtils.pm !!!
Was müsste man hier untersuchen? Ob es ohne die 3 Dateien geht?
OK, das steht dann wohl fest. Wenn wir den Übeltäter nicht finden, würde ich tatsächlich vorschlagen, die Routine selbst einzubauen.
Du könntest erstmal nachsehen, ob sich in den Dateien etwas in dieser Art findet:
sub round
Math::round
Verschiedene Möglichkeiten:
1) ich veröffentliche ein package mit der Round Funktion. Dann können auch andere sicher sein, die richtige round Funktion zu verwenden 2) wir schreiben unsere eigene Round FN in main und hoffen niemand überschreibt sie :)
@duko1234
Mich würde jetzt erstmal noch interessieren, ob bei dem SD_WS_110_TR bei den Temperaturwerten Nachkommastellen erscheinen, oder nur Ganzzahlen. Dort wird ja auch round verwendet.
Du könntest erstmal nachsehen, ob sich in den Dateien etwas in dieser Art findet:
sub round Math::round
duko1234@raspberrypi:/opt/fhem $ find -type f -name '*.p[lm]' -exec grep -i -n -w -H -P "sub\sround" "{}" ";"
./FHEM/00_SIGNALduino1.pm:394: Log3 $name, 1, "$name: Define, Signalduino can't be activated (sub round not found). Please update Fhem via update command";
./FHEM/00_SIGNALduino.pm:391: Log3 $name, 1, "$name: Define, Signalduino can't be activated (sub round not found). Please update Fhem via update command";
./restoreDir/update/2023-01-07/FHEM/00_SIGNALduino.pm:376: Log3 $name, 1, "$name: Define, Signalduino can't be activated (sub round not found). Please update Fhem via update command";
./restoreDir/update/2023-01-10/FHEM/00_SIGNALduino.pm:394: Log3 $name, 1, "$name: Define, Signalduino can't be activated (sub round not found). Please update Fhem via update command";
./restoreDir/update/2023-01-09/FHEM/00_SIGNALduino.pm:394: Log3 $name, 1, "$name: Define, Signalduino can't be activated (sub round not found). Please update Fhem via update command";
./restoreDir/2018-03-30/FHEM/00_SIGNALduino.pm:1579: Log3 $name, 1, "$name: Signalduino can't be activated (sub round not found). Please update Fhem via update command";
duko1234@raspberrypi:/opt/fhem $ find -type f -name '*.p[lm]' -exec grep -i -n -w -H -P "Math::round" "{}" ";"
./FHEM/45_Plugwise.pm:39:#use Math::Round;
./FHEM/99_myUtils.pm:12:use Math::Round;
./FHEM/00_SIGNALduino1.pm:40:#use Math::Round qw();
./FHEM/98_livetracking.pm:23:#use Math::Round;
./FHEM/98_livetracking.pm:1621: #return Math::Round::round($number);
./FHEM/31_MilightDevice.pm:34:#use Math::Round ();
./FHEM/31_MilightDevice.pm:2350: #return Math::Round::round($number);
./FHEM/31_MilightDevice.pm:2367: <p>Requires perl module Math::Round</p>
./restoreDir/update/2023-01-07/FHEM/98_livetracking.pm:23:#use Math::Round;
./restoreDir/update/2023-01-07/FHEM/98_livetracking.pm:1786: #return Math::Round::round($number);
./restoreDir/update/2023-01-07/FHEM/00_SIGNALduino.pm:35:#use Math::Round qw();
./restoreDir/update/2023-01-10/FHEM/00_SIGNALduino.pm:40:#use Math::Round qw();
./restoreDir/update/2023-01-09/FHEM/00_SIGNALduino.pm:40:#use Math::Round qw();
./restoreDir/2018-03-30/FHEM/00_SIGNALduino.pm:23:#use Math::Round qw();
Mich würde jetzt erstmal noch interessieren, ob bei dem SD_WS_110_TR bei den Temperaturwerten Nachkommastellen erscheinen, oder nur Ganzzahlen. Dort wird ja auch round verwendet.
Sowohl rain als auch temp sind nur ganzzahlig.
READINGS:
2023-01-16 18:42:33 batteryChanged 0
2023-01-16 22:06:33 batteryState ok
2023-01-16 22:06:33 rain 2
2023-01-16 22:06:33 rawRainCounter 20
2023-01-16 22:06:33 sendCounter 3
2023-01-16 22:06:33 state T: 22 R: 2
2023-01-16 22:06:33 temperature 22
2023-01-16 22:06:33 type ADE WS1907
Also nicht nur in der Momentaufnahme hier, sondern auch durchgehend im Log.
Deutet auf den Bedarf eines ordentlichen packages hin, was von mehreren Modulen verwendet werden kann.
Kann ich noch irgendwas tun, um zu unterstützen?
Ich denke, in dieser Datei steckt der Übeltäter:
./FHEM/99_myUtils.pm:12:use Math::Round;
Du könntest sie bearbeiten, oder gar löschen, wenn du sie nicht mehr brauchst. Diese Datei wurde vermutlich von dir selbst angelegt. Danach müsste FHEM eigentlich deine Sensoren wieder mit dem normalen Update, ohne unsere Änderungen, empfangen.
Ich denke, in dieser Datei steckt der Übeltäter:
./FHEM/99_myUtils.pm:12:use Math::Round;
Du könntest sie bearbeiten, oder gar löschen, wenn du sie nicht mehr brauchst. Diese Datei wurde vermutlich von dir selbst angelegt. Danach müsste FHEM eigentlich deine Sensoren wieder mit dem normalen Update, ohne unsere Änderungen, empfangen.
Also ich habe jetzt ein update gemacht, sodass ich wieder die "normale" 00_SignalDuino.pm aus dem repository bekommen habe. Anschließend habe ich die 99_myUtils.pm komplett auskommentiert, da ich sie eh nicht mehr brauche. Den "SD_WS_110_TR" habe ich gelöscht. Nach einem restart wurde der Sensor dann durch autocreate wieder nach der 3. message angelegt. Außerdem bekomme ich jetzt auch wieder Nachkommastellen. Damit könnte man das issue aus meiner Sicht schließen.
Wobei ich noch nicht ganz verstanden habe, wieso die 99_myUtils.pm jetzt Probleme macht. Dort werden ja nur math::Round und POSIX eingebunden, aber keine Neudefintion der Round Routinge vorgenommen.
Sowohl math::round als auch Posix registrieren eine round Funktion im Namespace Main.
FHEM, FHEM Module und auch die FHEM round Funktion liegen historisch auch alle im Namespace main.
Dein Issued zeigt, dass man sich in dieser verteilten Programmierung nicht auf subs in main verlassen kann. Um es an diesem Beispiel fest zu machen, kann sich kein Entwickler darauf verlassen, dass die FHEM eigene Round Routine aufruft. Damit ist diese Hilfsroutine so wie sie heute bereitgestellt wird unzuverlässig. Ich denke ich Stelle was in einem eigenen Package zur Verfügung und das Problem können so auch andere umgehen. Wobei interessant wäre, wer die Funktion überhaupt noch verwendet :)
Also ich habe jetzt ein update gemacht, sodass ich wieder die "normale" 00_SignalDuino.pm aus dem repository bekommen habe. Anschließend habe ich die 99_myUtils.pm komplett auskommentiert, da ich sie eh nicht mehr brauche. Den "SD_WS_110_TR" habe ich gelöscht. Nach einem restart wurde der Sensor dann durch autocreate wieder nach der 3. message angelegt. Außerdem bekomme ich jetzt auch wieder Nachkommastellen. Damit könnte man das issue aus meiner Sicht schließen.
Heißt das, das wir auch die Änderung, die ich in diesem Update eingebaut hatte
update all https://raw.githubusercontent.com/RFD-FHEM/RFFHEM/master_ade-ws1907/controls_signalduino.txt
nicht mehr benötigen? Der Sensor müsste etwa alle 45 Sekunden empfangen werden.
Zeile 1: 2023-01-17_19:41:46 SD_WS_110_TR T: 21.7 R: 3.2
Zeile 13: 2023-01-17_19:47:01 SD_WS_110_TR T: 21.7 R: 3.2
Zeile 23: 2023-01-17_19:52:16 SD_WS_110_TR T: 21.7 R: 3.2
Zeile 34: 2023-01-17_19:57:31 SD_WS_110_TR T: 21.7 R: 3.2
Zeile 44: 2023-01-17_20:02:46 SD_WS_110_TR T: 21.7 R: 3.2
Zeile 52: 2023-01-17_20:08:01 SD_WS_110_TR T: 21.8 R: 3.2
Zeile 58: 2023-01-17_20:08:46 SD_WS_110_TR T: 21.7 R: 3.2
Zeile 62: 2023-01-17_20:10:16 SD_WS_110_TR T: 21.8 R: 3.2
Zeile 65: 2023-01-17_20:11:01 SD_WS_110_TR T: 21.7 R: 3.2
Zeile 68: 2023-01-17_20:11:46 SD_WS_110_TR T: 21.8 R: 3.2
Zeile 71: 2023-01-17_20:12:31 SD_WS_110_TR T: 21.7 R: 3.2
Zeile 74: 2023-01-17_20:13:16 SD_WS_110_TR T: 21.8 R: 3.2
Zeile 84: 2023-01-17_20:20:01 SD_WS_110_TR T: 21.8 R: 3.2
Zeile 92: 2023-01-17_20:25:16 SD_WS_110_TR T: 21.8 R: 3.2
Zeile 104: 2023-01-17_20:31:16 SD_WS_110_TR T: 21.8 R: 3.2
Zeile 116: 2023-01-17_20:36:31 SD_WS_110_TR T: 21.8 R: 3.2
Ich glaube grundsätzlich kommen die messages alle 45 Sekunden. Die Aussetzer kommen wohl durch die Distanz zwischen Büro und dem Ort wo der Signalduino hängt. Denke da kommt aktuell nicht jede message an.
Bin wieder auf
versionmodul | 3.5.4
Denke deine Änderungen benötigen wir damit nicht mehr.
Das sieht gut aus. Vermutlich ist das Attribut "event-min-interval" noch auf ".*:300" eingestellt. D.h. es wird nur nach mindestens 5 Minuten ohne Änderung der Werte ein Event ausgelöst.
Das sieht gut aus. Vermutlich ist das Attribut "event-min-interval" noch auf ".*:300" eingestellt. D.h. es wird nur nach mindestens 5 Minuten ohne Änderung der Werte ein Event ausgelöst.
Stimmt, das macht mehr Sinn!
So ich hab die Round Funktion heute mal fix fertig gemacht: https://svn.fhem.de/trac/browser/trunk/fhem/lib/FHEM/Core/Utils/Math.pm?rev=27076
Mal schauen wie so die Resonanz ist :)
Resonanz gab es keine, aber die Funktion können wir jetzt einsetzen.
Immerhin gab es ja 1x "Gefällt mir" :-)
Expected Behavior
I bought a new ADE WS1907 rain gauge. I get messages from that rain gauge in fhem, but they are not recognized as a ADE WS1907 by fhem.
Actual Behavior
Above messages are not recognized as a ADE WS1907
Steps to Reproduce the Problem
1. 2. 3.
Specifications