search

RFD-FHEM / RFFHEM

Counterpart of SIGNALDuino, it's the code for FHEM to work with the data received from the uC
GNU General Public License v3.0
44 stars 33 forks source link

Water tank level monitor TS-FT002 #977

Closed docolli closed 3 years ago

docolli commented 3 years ago

Specifications for new sensor / switch / or other device ...

Specifications

I've already identified messages with the help of this project -> https://github.com/theovassiliou/WTLMReceiver They come exactly every 180s and are in sync with the receive signal indicator on the base LCD.

Signal 0 = +480/-480ms Signal 1 = +480/-960ms

RAWMSG: MU;P0=-2076;P1=479;P2=-963;P3=-492;P4=-22652;D=01213121213121212131313121313131312121313131313121212121313131212131313131313131313121313121313131313131313131312131212121313121412131212121212131213121213121212131313121313131312121313131313121212121313131212131313131313131313121313121313131313131313131;CP=1;R=26;O;
RAWMSG: MU;P0=-3508;P1=500;P2=-480;P3=-961;P4=-22648;D=01213131312121213121212121313121212121213131313121212131312121212121212121213121213121212121212121212121312131313121213141312131313131312131213131213131312121213121212121313121212121213131313121212131312121212121212121213121213121212121212121212121312131;CP=1;R=26;O;

I've already included into my local SD_Protocol.Data.pm the following defintion and activated protocoll 120:

    "120" =>  # Water Tank Level Monitor TS-FT002
              # MU;P0=-21720;P1=486;P2=-15724;P3=-482;P4=-970;D=01213141414131313141313131314141313131313141414141313131413141314131313131414131313141313131313131313131314131313141313141014131414141414131413141413141414131313141313131314
      {
        name            => 'TS-FT002',
        comment         => 'Water tank level monitor with temperature',
        id              => '120',
        knownFreqs      => '433.92',
        one             => [1,-1], # 480,-480
        zero            => [1,-2], # 480,-960
        start           => [-33],    # -15840
        clockabs        => 480,
        format          => 'twostate',
        clientmodule    => 'SD_WS',
        modulematch     => '^W120#',
        preamble        => 'W120#',
        reconstructBit   => '1',
        length_min      => '72',
        length_max      => '72',
      },

However, a new device with protocol 120 has not been added, but a device "SIGNALduino_unknown_31" using protocol ID 31. What have I done wrong in my definition?

Additionally taken from the other github project the protocol seems to be:

Temperature (of water tank)*10: Nibble 13 (High) - 12 (Middle) - 10 (Low) [in °C; -40, if invalid] Depth: Nibble 7 (High) - 6 (Middle) - 8 (Low) [in cm] Device ID: Nibble 4 (High) - 5 (Low) Serial: Nibble 3 (High) - 3 (Low) Battery: Nibble 9 TransmitInterval: Nibble 11

Check also WTLMReceiver.cpp for details.

elektron-bbs commented 3 years ago

Das kann so auch nichts werden, da "preamble => 'W120#'," nicht weiter verarbeitet wird. Probiere erstmal mit folgender Definition:

    "111" =>  # Water Tank Level Monitor TS-FT002
              # MU;P0=-21720;P1=486;P2=-15724;P3=-482;P4=-970;D=01213141414131313141313131314141313131313141414141313131413141314131313131414131313141313131313131313131314131313141313141014131414141414131413141413141414131313141313131314
      {
        name            => 'TS-FT002',
        comment         => 'Water tank level monitor with temperature',
        id              => '111',
        knownFreqs      => '433.92',
        one             => [1,-1], # 480,-480
        zero            => [1,-2], # 480,-960
        start           => [-47],  # -22560
        # start           => [-33],  # -15840
        clockabs        => 480,
        format          => 'twostate',
        # clientmodule    => 'SD_WS',
        # modulematch     => '^W120#',
        preamble        => 'u111#',
        reconstructBit   => '1', # wird nicht funktionieren, da High-Puls bei 0 und 1 gleich lang
        length_min      => '60',
        length_max      => '72',
      },

Damit sollte dir dann ein Device "SIGNALduino_unknown_111" angelegt werden, falls das Attribut "development" deines SIGNALduino auf 1 gesetzt ist. Damit kannst du zumindest erstmal Daten sammeln.

Bei "start" bin ich mir nicht sicher. Diese beiden Nachrichten werden bei -47 verarbeitet:

MU;P0=-2076;P1=479;P2=-963;P3=-492;P4=-22652;D=01213121213121212131313121313131312121313131313121212121313131212131313131313131313121313121313131313131313131312131212121313121412131212121212131213121213121212131313121313131312121313131313121212121313131212131313131313131313121313121313131313131313131;CP=1;R=26;O;
MU;P0=-3508;P1=500;P2=-480;P3=-961;P4=-22648;D=01213131312121213121212121313121212121213131313121212131312121212121212121213121213121212121212121212121312131313121213141312131313131312131213131213131312121213121212121313121212121213131313121212131312121212121212121213121213121212121212121212121312131;CP=1;R=26;O;

Diese bei -33:

MU;P0=-21720;P1=486;P2=-15724;P3=-482;P4=-970;D=01213141414131313141313131314141313131313141414141313131413141314131313131414131313141313131313131313131314131313141313141014131414141414131413141413141414131313141313131314;CP=1;R=26;O;
docolli commented 3 years ago

Danke Dir!

Bei "start" bin ich mir inzwischen sicher, dass -47 passender ist. Siehe das Log des detektierten 31er Protokolls.

SIGNALduino_unknown_31-2021.log

one/zero habe ich jetzt anders rum definiert, das war vorhin falsch. Ansonsten habe ich deine Definition übernommen:

   "111" =>  # Water Tank Level Monitor TS-FT002
              # MU;P0=-21720;P1=486;P2=-15724;P3=-482;P4=-970;D=01213141414131313141313131314141313131313141414141313131413141314131313131414131313141313131313131313131314131313141313141014131414141414131413141413141414131313141313131314
      {
        name            => 'TS-FT002',
        comment         => 'Water tank level monitor with temperature',
        id              => '111',
        knownFreqs      => '433.92',
        one             => [1,-2], # 480,-960
        zero            => [1,-1], # 480,-480
        start           => [-47],  # -22560
        clockabs        => 480,
        format          => 'twostate',
        #clientmodule    => 'SD_WS',
        #modulematch     => '^W120#',
        preamble        => 'u111#',
        reconstructBit   => '1',
        length_min      => '60',
        length_max      => '72',
      },

Das device SIGNALduino_unknown_111 wurde schon mal angelegt. Ich muss halt immer 3min. warten bis zur nächsten Nachricht. Dauert etwas bis man was zusammen hat 😉.

docolli commented 3 years ago 
2021-06-05_18:14:45 SIGNALduino_unknown_111 bitMsg: 101111101011011100010000110000011110001100100001100010000000000010011000
2021-06-05_18:14:45 SIGNALduino_unknown_111 bitMsg_invert: 010000010100100011101111001111100001110011011110011101111111111101100111
2021-06-05_18:14:45 SIGNALduino_unknown_111 bitCount: 72
2021-06-05_18:14:45 SIGNALduino_unknown_111 hexMsg: BEB710C1E321880098
2021-06-05_18:14:45 SIGNALduino_unknown_111 hexMsg_invert: 4148EF3E1CDE77FF67
2021-06-05_18:14:45 SIGNALduino_unknown_111 hexCount_or_nibble: 18
2021-06-05_18:14:45 SIGNALduino_unknown_111 lastInputDev: SignalDuino
2021-06-05_18:14:45 SIGNALduino_unknown_111 past_seconds: 0
2021-06-05_18:14:45 SIGNALduino_unknown_111 DMSG: u111#BEB710C1E321880098
2021-06-05_18:14:45 SIGNALduino_unknown_111 RSSI: -61
2021-06-05_18:14:45 SIGNALduino_unknown_111 Protocol_ID: 111
2021-06-05_18:14:45 SIGNALduino_unknown_111 RAWMSG: MU;P0=-27832;P1=476;P2=-21134;P3=-981;P4=308;P5=-503;D=01213451515131515151513131515151515131313131515151313151513151515151313151515131515151515151515151515131515131515131213151313131313151315131315131313151515131515151513131515151515131313131515151313151513151515151313151515131515151515151515151515131515131;CP=1;R=26;O;

Temp: 16.9°C Level: 0.27m

Ich habe 1.38m bis Zisterne ganz leer und 0.5m bis Zisterne ganz voll in der Basis definiert. Ich denke, der Sensor übermittelt der Basis nur den Abstand bis zur Wasseroberfläche und die rechnet dann den Rest aus.

Somit sollte der übermittelte Abstand 1.38m-0.27m=1.11m sein.

docolli commented 3 years ago 
2021-06-05_18:20:45 SIGNALduino_unknown_111 bitMsg: 101111101011011100010000110000011110001000100001100010000000000110010011
2021-06-05_18:20:45 SIGNALduino_unknown_111 bitMsg_invert: 010000010100100011101111001111100001110111011110011101111111111001101100
2021-06-05_18:20:45 SIGNALduino_unknown_111 bitCount: 72
2021-06-05_18:20:45 SIGNALduino_unknown_111 hexMsg: BEB710C1E221880193
2021-06-05_18:20:45 SIGNALduino_unknown_111 hexMsg_invert: 4148EF3E1DDE77FE6C
2021-06-05_18:20:45 SIGNALduino_unknown_111 hexCount_or_nibble: 18
2021-06-05_18:20:45 SIGNALduino_unknown_111 lastInputDev: SignalDuino
2021-06-05_18:20:45 SIGNALduino_unknown_111 past_seconds: 360
2021-06-05_18:20:45 SIGNALduino_unknown_111 RAWMSG: MU;P0=-21110;P1=484;P2=-971;P3=-488;D=01213121212121213121312121312121213131312131313131212131313131312121212131313121313131213131313121213131312131313131313131313131212131312131312101213121212121213121312121312121213131312131313131212131313131312121212131313121313131213131313121213131312131;CP=1;R=26;O;
2021-06-05_18:20:45 SIGNALduino_unknown_111 DMSG: u111#BEB710C1E221880193
2021-06-05_18:20:45 SIGNALduino_unknown_111 RSSI: -61
2021-06-05_18:20:45 SIGNALduino_unknown_111 Protocol_ID: 111

Temp: 16.8°C Level: 0.27m

docolli commented 3 years ago

Ich habe im Netz das hier gefunden:

Using the last data row as an example (010111110001110010001000010000001011000010000000111001000000000001101111 - 22.5 Celsius , 0.69m water level

Reading bytes 6 and 7 gives 10000000 and 11100100, reverse these bitwise giving 00000001 and 00100111 in other words nibbles 10, 11,12 and 13 are 0000, 0001, 0010 and 0111 or in hex 0, 1, 2, 7.

Unfortunately there does seem to be an error in the datasheet spreadsheet that was attached earlier – it seems it should be Temp_L = nibble 11, Temp_M = nibble 13, and Temp_H = nibble 12. Therefore temperature is 271 hex (not 127 hex)

Finishing off, 271 hex, = 625 decimal. Subtract the 400 offset gives 225 and divide by 10 gives the temperature of 22.5 degrees.

docolli commented 3 years ago

Das ist sicherlich auch hilfreich (der XC-0331 ist dem TS-FT002 sehr ähnlich, wenn nicht sogar gleich):

The XC-0331 uses a pulse-width method of sending 1's & 0's and all nibbles (18 of them) are bitswapped, ie; 1100 sent over the air is bitswapped to 0011.

Logic 0 = 480uS Logic 1 = 960uS

Thus 1100 would be sent as;

|------------960uS------------|------------960uS------------|------480uS------|------480uS------|

Nibbles are;

Bits are set MSB first, full sentence is 18 nibbles. Values below are AFTER bitswap.

Nibble Function 0 & 1 Sync [ 0xAF ] 2 & 3 Serial# Random Serial number choses and battery connection time. 4 & 5 DeviceID [0x11] ?? 6 -8 Depth_Med, depth_High, Depth_Low (Value in hex =cm, Fill with 5DC on invalid, range 0-15M) 9 Low Battery (0 = OK, any other value = Low) 10 Temp_Low 11 Transmit Interval ( Bit 7=0 180S, Bit 7 =1 30S, bit 4-6=1 5S) 12 &13 Temp_M, Temp_L (in hex *10, Max 1000, with 400 offset) If invalid read, filled with 3E8 14&15 Rain H, L (Value 0-256) not used in XC-0331 16&17 CRC (includes nibbles 2-15 only)

CRC is XOR of values from BYTES -0 to 7 ie;

Mycrc = (((((((byte0^byte1)^byte2)^byte3)^byte4)^byte5)^byte6)^byte7) = Byte8 (bitswapped)

elektron-bbs commented 3 years ago

Es fehlt zwar immer ein Bit am Anfang, aber die Temperatur konnte ich wahrscheinlich nachvollziehen: TS-FT002.xlsx

Ich bräuchte dann mal noch ein Log von dem Sensor um das genauer zu ermitteln, möglichst mit den Werten, die du von der Anzeige abgelesen hast (set SIGNALduino_unknown_111 UserInfo).

docolli commented 3 years ago

Du hast Recht, da fehlt uns noch ein Bit am Anfang. Da müssen wir wohl noch etwas an der Protokolldefinition feilen!

Ich glaube, ich habe damit jetzt die Höhe des Wasserspiegels gefunden (Basis hat als Tiefe der Zisterne 115cm):

                              DM   DH   DL
101 1111 0101 1011 1000 1000 0110 0000 0111 0001 0111 0000 0100 0100 0000 0000 1010 1001 1 -> Anzeige 0.05m
101 1111 0101 1011 1000 1000 1010 0000 1011 0001 0100 0000 0100 0100 0000 0000 1001 1001 1 -> Anzeige 0.22m
101 1111 0101 1011 1000 1000 1010 0000 0011 0001 0100 0000 0100 0100 0000 0000 0001 1100 0 -> Anzeige 0.23m

DM/DH/DL = Depth Mid/High/Low
Zusammengebaut und Bit reverse pro Nibble als 12Bit Wert:

0000.0110.1110 = 110 cm -> Basis rechnet 115cm - 110cm = 5cm
0000.0101.1101 = 93 cm  -> Basis rechnet 115cm - 93cm = 22cm
0000.0101.1100 = 92 cm  -> Basis rechnet 115cm - 92cm = 23cm

Der Sensor sendet also einfach den Abstand (von oben!) bis zur Wasseroberfläche in cm.

docolli commented 3 years ago

Und hier drei Messungen mit abgelesenen Werten von der Anzeige von heute Morgen:

2021-06-06_09:47:46 SIGNALduino_unknown_111 bitMsg: 101111101011011100010001010000010110001010000000100010000000000100110011
2021-06-06_09:47:46 SIGNALduino_unknown_111 bitMsg_invert: 010000010100100011101110101111101001110101111111011101111111111011001100
2021-06-06_09:47:46 SIGNALduino_unknown_111 bitCount: 72
2021-06-06_09:47:46 SIGNALduino_unknown_111 hexMsg: BEB711416280880133
2021-06-06_09:47:46 SIGNALduino_unknown_111 hexMsg_invert: 4148EEBE9D7F77FECC
2021-06-06_09:47:46 SIGNALduino_unknown_111 hexCount_or_nibble: 18
2021-06-06_09:47:46 SIGNALduino_unknown_111 lastInputDev: SignalDuino
2021-06-06_09:47:46 SIGNALduino_unknown_111 past_seconds: 1260
2021-06-06_09:47:46 SIGNALduino_unknown_111 RAWMSG: MU;P0=-3172;P1=495;P2=-487;P3=-963;P4=-22732;D=01212131213131212121312131212121212121213121212131212121212121212121213121213131212131413121313131313121312131312131313121212131212121312131212121212131213131212121312131212121212121213121212131212121212121212121213121213131212131;CP=1;R=32;
2021-06-06_09:47:46 SIGNALduino_unknown_111 Protocol_ID: 111
2021-06-06_09:47:46 SIGNALduino_unknown_111 RSSI: -58
2021-06-06_09:47:46 SIGNALduino_unknown_111 DMSG: u111#BEB711416280880133
2021-06-06_09:48:18 SIGNALduino_unknown_111 UserMSG: 14,6°C / 0,22m
2021-06-06_09:53:46 SIGNALduino_unknown_111 bitMsg: 101111101011011100010001010000000110001010000000100010000000000000110011
2021-06-06_09:53:46 SIGNALduino_unknown_111 bitMsg_invert: 010000010100100011101110101111111001110101111111011101111111111111001100
2021-06-06_09:53:46 SIGNALduino_unknown_111 bitCount: 72
2021-06-06_09:53:46 SIGNALduino_unknown_111 hexMsg: BEB711406280880033
2021-06-06_09:53:46 SIGNALduino_unknown_111 hexMsg_invert: 4148EEBF9D7F77FFCC
2021-06-06_09:53:46 SIGNALduino_unknown_111 hexCount_or_nibble: 18
2021-06-06_09:53:46 SIGNALduino_unknown_111 lastInputDev: SignalDuino
2021-06-06_09:53:46 SIGNALduino_unknown_111 past_seconds: 328
2021-06-06_09:53:46 SIGNALduino_unknown_111 RAWMSG: MU;P0=-30182;P1=479;P2=240;P3=-493;P4=-977;P5=-22708;D=01023141313131313131314141313131413141313131313131314131313141313131313131313131313131314141313141514131414141414131413141413141414131313141313131413141313131313131314141313131413141313131313131314131313141313131313131313131313131314141313141;CP=1;R=32;
2021-06-06_09:53:46 SIGNALduino_unknown_111 DMSG: u111#BEB711406280880033
2021-06-06_09:53:46 SIGNALduino_unknown_111 RSSI: -58
2021-06-06_09:53:46 SIGNALduino_unknown_111 Protocol_ID: 111
2021-06-06_09:54:17 SIGNALduino_unknown_111 UserMSG: 14.6°C / 0.23m
2021-06-06_09:56:46 SIGNALduino_unknown_111 bitMsg: 101111101011011100010001010000000110001010000000100010000000000000111000
2021-06-06_09:56:46 SIGNALduino_unknown_111 bitMsg_invert: 010000010100100011101110101111111001110101111111011101111111111111000111
2021-06-06_09:56:46 SIGNALduino_unknown_111 bitCount: 72
2021-06-06_09:56:46 SIGNALduino_unknown_111 hexMsg: BEB711406280880038
2021-06-06_09:56:46 SIGNALduino_unknown_111 hexMsg_invert: 4148EEBF9D7F77FFC7
2021-06-06_09:56:46 SIGNALduino_unknown_111 hexCount_or_nibble: 18
2021-06-06_09:56:46 SIGNALduino_unknown_111 lastInputDev: SignalDuino
2021-06-06_09:56:46 SIGNALduino_unknown_111 past_seconds: 149
2021-06-06_09:56:46 SIGNALduino_unknown_111 DMSG: u111#BEB711406280880038
2021-06-06_09:56:46 SIGNALduino_unknown_111 RSSI: -58
2021-06-06_09:56:46 SIGNALduino_unknown_111 Protocol_ID: 111
2021-06-06_09:56:46 SIGNALduino_unknown_111 RAWMSG: MU;P0=-3188;P1=471;P2=-21160;P3=-988;P4=-483;D=01213141414131414141314131414141414141413131414141314131414141414141413141414131414141414141414141414141413131414131213141313131313141314131314131313141414131414141314131414141414141413131414141314131414141414141413141414131414141414141414141414141413131;CP=1;R=32;O;
2021-06-06_09:57:10 SIGNALduino_unknown_111 UserMSG: 14.6°C / 0.23m
docolli commented 3 years ago 
2021-06-06_13:03:16 SIGNALduino_unknown_111 bitMsg: 101111101011011100010001010000000000001011000000100010000000000000010011
2021-06-06_13:03:16 SIGNALduino_unknown_111 bitMsg_invert: 010000010100100011101110101111111111110100111111011101111111111111101100
2021-06-06_13:03:16 SIGNALduino_unknown_111 bitCount: 72
2021-06-06_13:03:16 SIGNALduino_unknown_111 hexMsg: BEB7114002C0880013
2021-06-06_13:03:16 SIGNALduino_unknown_111 hexMsg_invert: 4148EEBFFD3F77FFEC
2021-06-06_13:03:16 SIGNALduino_unknown_111 hexCount_or_nibble: 18
2021-06-06_13:03:16 SIGNALduino_unknown_111 lastInputDev: SignalDuino
2021-06-06_13:03:16 SIGNALduino_unknown_111 past_seconds: 180
2021-06-06_13:03:16 SIGNALduino_unknown_111 RSSI: -60.5
2021-06-06_13:03:16 SIGNALduino_unknown_111 DMSG: u111#BEB7114002C0880013
2021-06-06_13:03:16 SIGNALduino_unknown_111 Protocol_ID: 111
2021-06-06_13:03:16 SIGNALduino_unknown_111 RAWMSG: MU;P0=-2744;P1=481;P2=-23470;P3=112;P4=-976;P5=248;P6=-696;P7=-488;D=012345617171417141717171717171717171717171417141417171717171714171717141717171717171717171717171717141717141214171414141414171417141417141414171717141717171417141717171717171717171717171417141417171717171714171717141717171717171717171717171717141717141;CP=1;R=27;
2021-06-06_13:04:46 SIGNALduino_unknown_111 UserMSG: 15.0°C / 0.35m

RAW-MSG: MU;P0=-2744;P1=481;P2=-23470;P3=112;P4=-976;P5=248;P6=-696;P7=-488;D=012345617171417141717171717171717171717171417141417171717171714171717141717171717171717171717171717141717141214171414141414171417141417141414171717141717171417141717171717171717171717171417141417171717171714171717141717171717171717171717171717141717141;CP=1;R=27;

Umrechnung:

                              DM   DH   DL
101 1111 0101 1011 1000 1000 1010 0000 0000 0001 0110 0000 0100 0100 0000 0000 0000 1001 1 -> Anzeige 0.35m
0000.0101.0000 = 80 -> 115cm - 80cm = 35cm

Und hier noch das komplette Log: SIGNALduino_unknown_111-2021.log

docolli commented 3 years ago

Weitere Infos zur Protokolldefinition aus dem Netz (rtl_433):

PPM with 500 us pulse, 464 us short gap (0), 948 us long gap (1), 1876 us packet gap, two packets per transmission.

Wie definiere ich die PPM Codierung? Mit format=pwm? Ich bin noch auf der Suche nach dem fehlenden Bit "0" zu Beginn der Nachricht.

Es hat sich übrigens auch ein Device "SIGNALduino_unknown_31" angelegt und loggt fröhlich Nachrichten. Hilft eventuell die passende Definition zu finden.

Hier das Log dazu: SIGNALduino_unknown_31-2021.log

sidey79 commented 3 years ago

PWM kann wie folgt hinterlegt werden:

https://github.com/RFD-FHEM/RFFHEM/blob/e4634de6baf5b52b250a0aecaadf1b30b7df6c12/FHEM/lib/SD_ProtocolData.pm#L60

PPM sagt mir jetzt nichts. Soll das für Pulse Pause Message stehen?

docolli commented 3 years ago

Danke für den Tip, für mich steht PPM für Pulse Pause Modulation. Hat aber alles nix gebracht.

Ich verwende jetzt folgende Definition:


        name            => 'TS-FT002',
        comment         => 'Water tank level monitor with temperature',
        id              => '111',
        knownFreqs      => '433.92',
        one             => [1,-2], # 480,-960
        zero            => [1,-1], # 480,-480
        start       => [1,-2,1,-1,1,-2,1,-2,1,-2,1,-2,1,-2],  # Sync -22560 / 101.1111
        pause       => [-46],
        clockabs        => 480,
        format          => 'twostate',
        remove_zero => '0',
        #clientmodule    => 'SD_WS',
        #modulematch     => '^W120#',
        preamble        => 'u111#',
        #reconstructBit   => '1',
        length_min      => '64',
        length_max      => '72',

Damit kann ich die meisten Nachrichten, die alle 180s kommen, erfolgreich abfangen:


2021-06-07_20:01:51 SIGNALduino_unknown_111 bitMsg: 0101101110001000010000000110000111100000110001000000000010001001
2021-06-07_20:01:51 SIGNALduino_unknown_111 bitMsg_invert: 1010010001110111101111111001111000011111001110111111111101110110
2021-06-07_20:01:51 SIGNALduino_unknown_111 bitCount: 64
2021-06-07_20:01:51 SIGNALduino_unknown_111 hexMsg: 5B884061E0C40089
2021-06-07_20:01:51 SIGNALduino_unknown_111 hexMsg_invert: A477BF9E1F3BFF76
2021-06-07_20:01:51 SIGNALduino_unknown_111 hexCount_or_nibble: 16
2021-06-07_20:01:51 SIGNALduino_unknown_111 lastInputDev: SignalDuino
2021-06-07_20:01:51 SIGNALduino_unknown_111 past_seconds: 185
2021-06-07_20:01:51 SIGNALduino_unknown_111 Protocol_ID: 111
2021-06-07_20:01:51 SIGNALduino_unknown_111 DMSG: u111#5B884061E0C40089
2021-06-07_20:01:51 SIGNALduino_unknown_111 RAWMSG: MU;P0=-112;P1=276;P2=-479;P3=482;P4=208;P6=-981;P7=-22648;D=01232123232423636323232323636363632323232323636323232363232323232323232323236323232363232363736323636363636323632363632363636323232363232323236323232323232323636323232323636363632323232323636323232363232323232323232323236323232363232363;CP=3;R=21;
2021-06-07_20:01:51 SIGNALduino_unknown_111 RSSI: -63.5

Zusätzlich habe ich kein Problem mehr mit dem fehlenden "0" Bit am Anfang und dem Nibble Alignment:

SER  SER   ID   ID   DM   DH   DL  BAT   TL  INT   TM   TH   RH   RL  CRC  CRC
0101.1011.1000.1000.0100.0000.0110.0001.1110.0000.1100.0100.0000.0000.1000.1001

Kann mir bitte jemand helfen diese Bitfolge im Modul SD_WS so zu interpretieren, dass Füllhöhe, Temp und Bat ausgewertet werden?

HomeAutoUser commented 3 years ago

@docolli, das klingt schonmal ganz gut.

Kann mir bitte jemand helfen diese Bitfolge im Modul SD_WS so zu interpretieren, dass Füllhöhe, Temp und Bat ausgewertet werden?

Das beste ist, du musst mal ein wenig loggen mit dem SIGNALduino_unknown_111 device und via set SIGNALduino_unknown_111 UserInfo jeweils die Zustände der Station dokumentieren. Wenn du dies mit einigen Zuständen der möglichkeiten erledigt hast, so wissen wir alle Bits. Diese einzubauen würden wir auch noch erledigen bei Bedarf. Kurzgesagt, du musst Inputs liefern, damit wir das vollständige Signal deuten können. Dann können wir zeitnah das Modul anpassen.

EDIT:

SER  SER   ID   ID   DM   DH   DL  BAT   TL  INT   TM   TH   RH   RL  CRC  CRC
0101.1011.1000.1000.0100.0000.0110.0001.1110.0000.1100.0100.0000.0000.1000.1001

Ist das vollständig getestet? Hast du auch den Batt Zustand gestest? (normal / low)

docolli commented 3 years ago

Ja, das passt sehr gut zu den Werten auf der Anzeige. Wobei diese die Füllhöhe ja umrechnet und den Füllstand in cm vom tiefsten Punkt der Zisterne anzeigt. Diesen "Basiswert" muss man der Anzeige eingeben. Der Sensor gibt aber nur stupide die Distanz (in cm) zur Wasseroberfläche aus.

Bei allen Nibbles muss ein Bitswap gemacht werden!

Ich mache das mal Beispielhaft für das obige Datagram:

SER = 0101.1011 -> SWAP -> 1010.1101 => 0xAD
ID = 1000.1000 -> SWAP -> 0001.0001 => 0x11
DH/DM/DL (Abstand zum Wasser) = 0000.0100.0110 -> SWAP -> 0000.0010.0110 => 0x26 = 38[cm]
BAT = 0001 -> SWAP -> 1000 => Bat OK
TH/TM/TL (Temperatur) = 0100.1100.1110 -> SWAP -> 0010.0011.0111 => 0x237 = 567 - 400 (Offset) = 167 / 10 = 16.7°C
RH/RL (Rain) = 0000.0000 (bei diesem Sensor unbenutzt!)
CRC = 1000.1001 (ist das hier notwendig?)

Siehe auch https://github.com/RFD-FHEM/RFFHEM/issues/977#issuecomment-855277726

elektron-bbs commented 3 years ago

Ich habe mir da jetzt anders beholfen: Immer, wenn die Nachricht mit 0xBE beginnt, wird noch ein Bit 0 vor die Bitdaten gehangen. So haben wir immer die Bitfolgen, wie beschrieben.

Ich habe einen neuen Branch erstellt: master_TS-FT002 Ein Update darauf kannst du mit folgendem Befehl machen:

update all https://raw.githubusercontent.com/RFD-FHEM/RFFHEM/master_TS-FT002/controls_signalduino.txt

Das Reading "batteryState" ist noch unklar - zeigt hier immer low. Bei dem Reading "interval" bin ich mir nicht sicher, ob ich das reversed oder nicht auswerten muss.

Die Mindestlänge der Nachrichten habe ich jetzt auf 71 gesetzt. Allerdings fehlen bei den Nachrichten oft einige Bits, weil zwei Nachrichten mit einer Länge von jeweils 72 Bit übertragen werden. Damit ist der Puffer vom SIGNALduino überfordert.

Bitte mal testen und dann berichten.

docolli commented 3 years ago

Vielen Dank!

Damit kann ich was anfangen. Ich teste jetzt mal übers WE bis Montag und melde mich dann wieder.

Ich habe übrigens die Protokolldefinition noch verfeinert und auch Änderungen am Modulcode für das "111" Protokoll vorgenommen. Wir diskutieren dann nächste Woche, wenn es mit den Änderungen erfolgreich geklappt hat Werte aufzuzeichnen.

docolli commented 3 years ago

Positive Zwischenbilanz!

Mit dieser Protokolldefinition:

        name            => 'TS-FT002',
        comment         => 'Water tank level monitor with temperature',
        id              => '111',
        knownFreqs      => '433.92',
    one             => [1,-2], # 480,-960
        zero            => [1,-1], # 480,-480
        start       => [1,-2, 1,-1, 1,-2, 1,-2, 1,-2, 1,-2, 1,-2],  # Sync 101.1111
        pause       => [-47],# -22080
        clockabs        => 480,
        format          => 'twostate',
        clientmodule    => 'SD_WS',
        modulematch     => '^W111#',
        preamble        => 'W111#',
        length_min      => '60',
        length_max      => '72',

bekomme ich 421 Logeinträge innerhalb 24h (Erwartet 480 bei alle 3min. 1 Datagram; 24*60/3 = 480) 24h Datagram Log.txt

Auch die heutige Wasserentnahme wurde sauber aufgezeichnet: Graph_1

elektron-bbs commented 3 years ago

Mit length_min => '60', fehlt uns aber die Prüfung der Nachricht. Man sieht in deinem Diagramm bei der Temperatur gut, das ab und an fehlerhafte Werte durchkommen. Mich würde interessieren, wie viele Nachrichten mit length_min => '71', b.z.w. bei deiner Variante mit length_min => '64', empfangen werden. Da wäre die Prüfung mit dabei (hatte ich aber noch nicht eingebaut).

Deine Datei 24h Datagram Log.txt nützt mir leider wenig. Bitte lade mal das Log vom Sensor und deine 14_SD_WS.pm hoch.

docolli commented 3 years ago

Ja, das mit den Temperatur-Spikes finde ich auch noch sehr interessant. Da dies eben stattgefunden hat, hier die Werte:

|| *TIMESTAMP* || *DEVICE* || *TYPE* || *EVENT* || *READING* || *VALUE* || *UNIT* ||
|| 2021-06-12 13:47:48 || SD_WS_111_TL || SD_WS || temperature: 19.1 || temperature || 19.1 || °C ||
|| 2021-06-12 13:44:48 || SD_WS_111_TL || SD_WS || temperature: 20 || temperature || 20 || °C ||
|| 2021-06-12 13:38:48 || SD_WS_111_TL || SD_WS || temperature: 19 || temperature || 19 || °C ||

Und das Log vom Sensor für diese 3 Werte:

2021-06-12_13:38:48 SD_WS_111_TL T: 19 D: 47
2021-06-12_13:38:48 SD_WS_111_TL temperature: 19
2021-06-12_13:38:48 SD_WS_111_TL distance: 47
2021-06-12_13:38:48 SD_WS_111_TL interval: 180
2021-06-12_13:38:48 SD_WS_111_TL RAWMSG: MU;P0=-31628;P1=469;P2=-980;P3=-499;P4=-22684;D=01213121212121213121312121312121213131312131313131213131313131312121212131313121312121213131313131312131312131313131313131313131312121312131312141213121212121213121312121312121213131312131313131213131313131312121212131313121312121213131313131312131312131;CP=1;R=38;O;
2021-06-12_13:38:48 SD_WS_111_TL DMSG: W111#5B8840F170240069
2021-06-12_13:38:48 SD_WS_111_TL RSSI: -55
2021-06-12_13:38:48 SD_WS_111_TL Protocol_ID: 111
2021-06-12_13:44:48 SD_WS_111_TL T: 20 D: 47
2021-06-12_13:44:48 SD_WS_111_TL temperature: 20
2021-06-12_13:44:48 SD_WS_111_TL distance: 47
2021-06-12_13:44:48 SD_WS_111_TL interval: 180
2021-06-12_13:44:48 SD_WS_111_TL level: 68
2021-06-12_13:44:48 SD_WS_111_TL percent: 88
2021-06-12_13:44:48 SD_WS_111_TL DMSG: W111#5B8840F110A40089
2021-06-12_13:44:48 SD_WS_111_TL RAWMSG: MU;P0=-5980;P1=464;P2=-988;P3=-511;P4=-22660;D=01213121212121213121312121312121213131312131313131213131313131312121212131313121313131213131313121312131312131313131313131313131213131312131312141213121212121213121312121312121213131312131313131213131313131312121212131313121313131213131313121312131312131;CP=1;R=38;O;
2021-06-12_13:44:48 SD_WS_111_TL RSSI: -55
2021-06-12_13:44:48 SD_WS_111_TL Protocol_ID: 111
2021-06-12_13:47:48 SD_WS_111_TL T: 19.1 D: 47
2021-06-12_13:47:48 SD_WS_111_TL temperature: 19.1
2021-06-12_13:47:48 SD_WS_111_TL distance: 47
2021-06-12_13:47:48 SD_WS_111_TL interval: 180
2021-06-12_13:47:48 SD_WS_111_TL DMSG: W111#5B8840F1F02400E9
2021-06-12_13:47:48 SD_WS_111_TL RAWMSG: MU;P0=-22366;P1=473;P2=-985;P3=-499;D=01213121212121213121312121312121213131312131313131213131313131312121212131313121212121213131313131312131312131313131313131313131212121312131312101213121212121213121312121312121213131312131313131213131313131312121212131313121212121213131313131312131312131;CP=1;R=38;O;
2021-06-12_13:47:48 SD_WS_111_TL RSSI: -55
2021-06-12_13:47:48 SD_WS_111_TL Protocol_ID: 111

Ich habe gerade keine Zeit mir das selber genauer anzuschauen, bin noch an einem anderen Projekt im Haus tätig. 😅 Hier das komplette Log vom Sensor seit ich das Protokoll umgestellt habe:

SIGNALduino_unknown_111-2021.log

Zur 14_SD_WS.pm möchte ich gerne in paar Anmerkungen dazuschreiben, wieso ich was geändert habe 😉. Aber damit du die Auswertung schon mal nachvollziehen kannst, hier die Datei:

14_SD_WS_08.06.2021.pm.txt

PS: Was schlägst Du als length_min / length_max vor? Kann ich dann gerne testen.

elektron-bbs commented 3 years ago

Leider die falsche Logdatei :-( Wenn eine Prüfung erfolgen soll, brauchen wir die kompletten 72 Bit. Bei deiner Variante ohne Byte 0 wären es dann halt 64 Bit.

docolli commented 3 years ago

Hier jetzt die Richtige (Sorry!!!): SD_WS_111_TL-2021_11.06.2021.log

Aktuell bekomme ich stabil die 64 Bit. Als Byte 0 nehmen wir eben die von den anderen ermittelten 0xAF (mit Bitswap in den Nibbles) bzw. 0x5F für die CRC Prüfung.

elektron-bbs commented 3 years ago

Ich habe jetzt deine Änderungen soweit übernommen und teste noch etwas mit deinen Logdaten. Die Prüfung habe ich auch eingebaut.

elektron-bbs commented 3 years ago

Ich habe jetzt ein commit durchgeführt. Bitte nochmal ein Update auf den Branch durchführen und FHEM neu starten, da sich die SD_ProtocolData.pm geändert hat.

Hast du das Reading "batteryState" nur auf Verdacht geändert, oder wirklich probiert? Stimmt das Reading "interval" bei allen Werten (5, 30 und 180)?

docolli commented 3 years ago

Update erfolgreich durchgeführt. Geräteempfang läuft weiterhin.

Das Reading "batteryState" habe ich tatsächlich nur meinem aktuell empfangenem Nibble angepasst. Das muss ich noch mit älteren Batterien testen. Ich weiß noch nicht, wie ich das Reading "interval" testen soll. Bislang bekomme ich (auch über die Basis angezeigt) nur alle 3 min. ein Datagram. Laut Doku: "tank level updated 30s or 3min", aber WANN macht er 30s?

Ich muss auch noch einen Batteriewechsel testen, dann sollte sich die ID ändern. Bin gespannt, ob da dann auch irgendein anderes Bit gesetzt wird. Wenn ich das mache, setzte ich den SignalDuino auf verbose=5.

Ach ja, wie schaue ich, ob die CRC Prüfung erfolgreich/fehlerhaft war? Genügt da verbose=1 und Blick ins FHEM Log?

docolli commented 3 years ago

Zu meinen Änderungen an der 14_SD_WS.pm:

Wie du gesehen hast, habe ich den Namen distance anstatt depth für das Reading des Sensors gewählt. Ich finde das sagt klarer aus, was der Messwert des Sensors wirklich bedeutet. Er misst ja nicht die Wassertiefe, sondern "nur" den Abstand des Wasserspiegels zum Sensor hin. Die tatsächliche Wassertiefe bis zum Boden des Tanks muss selber berechnet werden.

Ich habe mir dazu beim device zwei userAttribute angelegt:

userattr tank-distance-min tank-distance-max
tank-distance-max 115
tank-distance-min 38

tank-distance-max ist die maximale Distanz, die der Sensor misst, wenn der Tank leer ist. tank-distance-min ist die minimale Distanz, die der Sensor misst, wenn der Tank voll ist.

Berechnet werden daraus folgende userReadings:

level { AttrVal($NAME,'tank-distance-max',0)-ReadingsVal($NAME,"distance",0);; }, 
percent { int(100*((AttrVal($NAME,'tank-distance-max',0)-ReadingsVal($NAME,"distance",0))/(AttrVal($NAME,'tank-distance-max',1)-AttrVal($NAME,'tank-distance-min',0))));; }

level ist der tatsächliche Wasserstand in cm percent ist der Füllstand in %

Können solche userAttribute bzw. userReadings auch gleich beim automatischen Anlegen des device mit angelegt werden? Dann müsste ein anderen FHEM Anwender nur noch seine Werte für tank-distance-max und tank-distance-min eingeben.

elektron-bbs commented 3 years ago

Ich weiß noch nicht, wie ich das Reading "interval" testen soll. Bislang bekomme ich (auch über die Basis angezeigt) nur alle 3 min. ein Datagram. Laut Doku: "tank level updated 30s or 3min", aber WANN macht er 30s?

Ich habe im Internet eine Excel-Tabelle gefunden (https://forum.arduino.cc/t/help-with-decoding-433-mhz-rf-xc-0331-wireless-ultrasonic-tank-level-meter/234668/11). Dort steht:

1, the initial power on each 5S test and launch, only 5 launches, enter the normal mode;
2, the normal mode, if the test height change will fast test and emission (30S cycle), two times the same test data until after the turn into normal test and emission (180S cycle);
3, Transmit data each of the two frames and  21.8MS for intermediate.

Ich muss auch noch einen Batteriewechsel testen, dann sollte sich die ID ändern. Bin gespannt, ob da dann auch irgendein anderes Bit gesetzt wird. Wenn ich das mache, setzte ich den SignalDuino auf verbose=5.

Das wäre gut.

Ach ja, wie schaue ich, ob die CRC Prüfung erfolgreich/fehlerhaft war? Genügt da verbose=1 und Blick ins FHEM Log?

Verbose 3 beim Sensor reicht, verbose 1 unterdrückt ja fast alle Meldungen. Die Ausgabe wird in dieser Zeile gebildet:

Log3 $name, 3, "$name: SD_WS_111 Parse msg $msg - ERROR check $xor != 0";

elektron-bbs commented 3 years ago

Wie du gesehen hast, habe ich den Namen distance anstatt depth für das Reading des Sensors gewählt. Ich finde das sagt klarer aus, was der Messwert des Sensors wirklich bedeutet. Er misst ja nicht die Wassertiefe, sondern "nur" den Abstand des Wasserspiegels zum Sensor hin. Die tatsächliche Wassertiefe bis zum Boden des Tanks muss selber berechnet werden.

Ich finde den Namen auch passender, man muss den Sensor ja nicht zwangsläufig in einen Tank hängen, dann misst er halt den Abstand :-)

Können solche userAttribute bzw. userReadings auch gleich beim automatischen Anlegen des device mit angelegt werden? Dann müsste ein anderen FHEM Anwender nur noch seine Werte für tank-distance-max und tank-distance-min eingeben.

Könnte man prinzipiell machen, ist aber bei den Entwicklern nicht gern gesehen. Vielleicht nehme ich es in die Hilfe auf.

docolli commented 3 years ago

Wie du gesehen hast, habe ich den Namen distance anstatt depth für das Reading des Sensors gewählt. Ich finde das sagt klarer aus, was der Messwert des Sensors wirklich bedeutet. Er misst ja nicht die Wassertiefe, sondern "nur" den Abstand des Wasserspiegels zum Sensor hin. Die tatsächliche Wassertiefe bis zum Boden des Tanks muss selber berechnet werden.

Ich finde den Namen auch passender, man muss den Sensor ja nicht zwangsläufig in einen Tank hängen, dann misst er halt den Abstand :-)

Können solche userAttribute bzw. userReadings auch gleich beim automatischen Anlegen des device mit angelegt werden? Dann müsste ein anderen FHEM Anwender nur noch seine Werte für tank-distance-max und tank-distance-min eingeben.

Könnte man prinzipiell machen, ist aber bei den Entwicklern nicht gern gesehen. Vielleicht nehme ich es in die Hilfe auf.

Das wäre gut, dann bekommt man so wenigstens den Hinweis, wie man zur Füllhöhe kommt

Ich habe versucht, den Sensor in den BatteryLow Zustand zu bekommen. Mit seinen 6xAAA Batterien bekommt er gemessen ~9,5V. Durch Einsetzen alter Batterien bin ich bis auf 5,2V runter, dennoch zeigt die Basis immer noch kein BatteryLow Symbol an. Als ich bei 4.5V war, hatte ich Probleme, dass die Basis den Sensor nach dem (nötigen) Batteriewechsel noch erkennt. Aktuell kann ich also zum BatterieBit nichts beitragen. Wir können es ja mal so lassen.

docolli commented 3 years ago

Hier das FHEM log vom Batteriewechsel (war so gegen 14h).

BatteryChange_13.06.2021.log

Zusätzlich noch Daten vom BatterieLow Test (versch. ID), der Sensor stand direkt auf dem Tisch (Abstand = 0cm):

DMSG: W111#5F5B88C00110240079
DMSG: W111#5F9C88777150E400F9
DMSG: W111#5F36887771C0140033
DMSG: W111#5F0C887771F0E400C9
DMSG: W111#5F16887771A09400F3
elektron-bbs commented 3 years ago

Tja, leider ist weder bei "batteryState" noch bei "interval" eine Änderung sichtbar :-(

docolli commented 3 years ago

Mal so'ne Idee:

Der Signalduino kann doch auch senden, oder? Könnte ich damit einen Sensor emulieren? Beim echten Sensor würde ich dann die Batterien rausnehmen, damit der nicht dazwischen funkt.

Dann könnte man erstmal versuchen den Fake-Sensor an die Basis zu koppeln und versch. Temperaturen zum Test senden. Wenn das klappt, könnte man mal an den Bits für den vermeintlichen BatteryState spielen.

Was meinst Du? Und wie würde ich das dann konkret machen müssen, um was zu senden?

sidey79 commented 3 years ago

Könnte man prinzipiell machen, ist aber bei den Entwicklern nicht gern gesehen. Vielleicht nehme ich es in die Hilfe auf.

Die Attribute könnten über ein Attribut Template durch den Anwender gesetzt werden

elektron-bbs commented 3 years ago

@docolli Kannst du irgendwie die Auslastung deines Systems, speziell RAM-Nutzung und CPU-Last nachverfolgen?

Ich habe hier den Effekt, das nach Aktivierung dieses Protokolls nach kurzer Zeit der RAM zu 100% belegt wird und FHEM nicht mehr reagiert. Das Testsystem bei mir ist ein Raspberry Pi 3 und ich verwende u.a. sysmon um das System zu überwachen. Ich konnte die Ursache zwar jetzt schon eingrenzen, wüsste aber gern, ob das auch bei dir auftritt.

docolli commented 3 years ago

@elektron-bbs Nachverfolgen im Sinne von historischen Daten leider nicht, aber hier der aktuelle Stand:

top - 08:47:41 up 27 days, 11:17,  1 user,  load average: 0,38, 0,16, 0,06
Tasks: 106 total,   1 running, 105 sleeping,   0 stopped,   0 zombie
%Cpu(s):  0,4 us,  0,3 sy,  0,0 ni, 99,3 id,  0,0 wa,  0,0 hi,  0,0 si,  0,0 st
MiB Mem :    924,2 total,    551,4 free,    309,3 used,     63,5 buff/cache
MiB Swap:    100,0 total,     62,4 free,     37,6 used.    562,9 avail Mem

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
31450 fhem      20   0  293492 276408   7248 S   0,3  29,2   3:39.79 perl

Das sieht bei mir nicht kritisch aus! Und das Protokoll läuft bei mir schon seit einer Woche. Ich stelle auch keine Probleme mit meinem FHEM auf dem Raspi fest.

Linux 5.10.17-v7+ #1403 SMP Mon Feb 22 11:29:51 GMT 2021 armv7l GNU/Linux

elektron-bbs commented 3 years ago

Interessant wäre ein Vergleich, wenn das Protokoll nicht aktiv ist. Ich habe den Verdacht, das die lange Start-Definition der Verursacher ist.

start => [1,-2, 1,-1, 1,-2, 1,-2, 1,-2, 1,-2, 1,-2], # Sync 101.1111

Mit dieser Einstellung ist nach wenigen Sekunden RAM und Swap voll belegt und CPU-Last auf 100% - das System lässt sich nicht mehr bedienen und speichert auch keine Daten mehr. Ich habe die Definition dann stufenweise gekürzt:

        # start           => [1,-2, 1,-1, 1,-2, 1,-2, 1,-2, 1,-2, 1,-2], # Sync 101.1111
        # start           => [1,-1, 1,-2, 1,-2, 1,-2, 1,-2, 1,-2], # Sync 01.1111
        start             => [1,-2, 1,-2, 1,-2, 1,-2, 1,-2], # Sync 1.1111

Erst mit dem letzten Eintrag läuft das System wieder zuverlässig. Im Screenshot sieht man in den ersten zwei Stunden eine starke Auslastung. Zu dieser Zeit war der 2. Eintrag aktiv. P111

docolli commented 3 years ago

Das sieht ja so aus, als ob du mit FHEM auch die Systemparameter protokollierst! Wenn du mir sagst, wie das geht, baue ich das gerne nach und dann vergleiche ich mit/ohne Protokoll aktiv. Oder sind das andere gplot Graphen?

docolli commented 3 years ago 
top - 19:33:49 up 27 days, 22:03,  1 user,  load average: 0,03, 0,06, 0,00
Tasks: 107 total,   1 running, 106 sleeping,   0 stopped,   0 zombie
%Cpu(s):  1,3 us,  0,0 sy,  0,0 ni, 98,7 id,  0,0 wa,  0,0 hi,  0,1 si,  0,0 st
MiB Mem :    924,2 total,    318,3 free,    537,9 used,     68,0 buff/cache
MiB Swap:    100,0 total,     53,9 free,     46,1 used.    333,5 avail Mem

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
 3149 fhem      20   0  517980 499212   7432 S   3,9  52,7   7:42.05 perl

Ich habe das Protokoll 111 deaktiviert. Sieht nicht nach dem aus, was du suchst.

whitelist IDs: 0,0.2,0.3,0.5,1,3,3.1,4,6,7,8,9,10,11,12,13,13.1,13.2,14,17,17.1,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,33.1,33.2,35,36,37,38,39,40,41,42,43,44,44.1,45,46,47,48,49,49.1,49.2,50,51,52,53,54,54.1,55,56,57,58,59,60,61,62,64,65,66,67,68,69,70,71,72,73,74,74.1,76,79,80,81,83,84,85,86,87,88,89,90,91,91.1,92,93,94,95,96,97,98,99,104,110

docolli commented 3 years ago

Oh, ich habe soeben verstanden, dass es ein FHEM Modul Sysmon gibt! 😁 Ich baue das bei mir ein...

docolli commented 3 years ago

Aktueller Stand: grafik

Ich lass es bis morgen Abend mal laufen. Protokoll 111 ist aktiv!

elektron-bbs commented 3 years ago

Ich danke dir für die Mithilfe. Verursacher müssen Nachrichten sein, die nicht zu diesem Protokoll passen. Ich habe zwar das Protokoll aktiv, es werden aber keine Nachrichten von diesem Sensor dekodiert. Wir haben den Effekt auch auf einem anderen System beobachtet. Dort mussten wir aber länger warten, bis das System blockierte, vermutlich weil dort erheblich weniger Sensoren aktiv sind.

Hier ist da erheblich mehr Traffic:

Uptime: 1 days, 02 hours

Device             MSGCNT
-------------------------
sduinoACM           13897 
sduinoD1             5923 
sduinoEasyPico868     751 
sduinoIP            58677 = 37,6 MSG/Minute 
sduinoUSB0          30228
docolli commented 3 years ago

Heute morgen um 7:30h habe ich auf einmal mehr freien RAM. Ich habe aktiv aber nichts gemacht und ob das was mit FHEM zu tun hat, kann ich auch nicht sagen: grafik

So wie du es beschreibst, hört sich dass vermutlich nach einem Speicherleck an. Bei Dir kommen viele Nachrichten rein, von denen eine Menge fälschlicherweise als Protokoll 111 interpretiert werden. Zur Verarbeitung jeder Nachricht wird Speicher reserviert, dann bricht aber die Verarbeitung ab (ist halt doch keine 111er Nachricht), der reservierte Speicher wird dann aber nicht mehr freigegeben.

Edit: Ist eventuell ein Perl Problem: https://forum.fhem.de/index.php/topic,84372.0.html https://forum.fhem.de/index.php?topic=88291.0

perl -v
This is perl 5, version 28, subversion 1 (v5.28.1) built for arm-linux-gnueabihf-thread-multi-64int

Ich kenne jetzt das Konzept SignalDuino -> RFFHEM gar nicht, kann also aktuell nichts konkreteres beitragen. Gibt es irgendwo eine Doku, die das beschreibt?

elektron-bbs commented 3 years ago

Heute morgen um 7:30h habe ich auf einmal mehr freien RAM. Ich habe aktiv aber nichts gemacht und ob das was mit FHEM zu tun hat, kann ich auch nicht sagen:

Tja, was der Raspi da gegen 7:30 getan hat, kannst nur du heraus finden. Bei mir passiert so etwas z.B. immer beim täglichen Backup 12:00 Uhr.

So wie du es beschreibst, hört sich dass vermutlich nach einem Speicherleck an. Bei Dir kommen viele Nachrichten rein, von denen eine Menge fälschlicherweise als Protokoll 111 interpretiert werden. Zur Verarbeitung jeder Nachricht wird Speicher reserviert, dann bricht aber die Verarbeitung ab (ist halt doch keine 111er Nachricht), der reservierte Speicher wird dann aber nicht mehr freigegeben.

So ähnlich wird das sein. Ich vermute, die Verarbeitung ungültiger Nachrichten dauert zu lange. Ich habe mal einen Benchmark geschrieben, der die Startsequenz im Datenteil sucht. Wenn die Startsequenz gar nicht enthalten ist, dauert das etwa 4 mal solange.

                # Rate notfound5 notfound7 notfound6 found6at139 found7at139 found5at139 found7at1 found6at2 found5at3
# notfound5    84626/s        --       -2%       -7%        -20%        -30%        -36%      -62%      -71%      -73%
# notfound7    85963/s        2%        --       -5%        -18%        -29%        -35%      -62%      -71%      -72%
# notfound6    90755/s        7%        6%        --        -14%        -25%        -31%      -59%      -69%      -71%
# found6at139 105391/s       25%       23%       16%          --        -12%        -20%      -53%      -64%      -66%
# found7at139 120399/s       42%       40%       33%         14%          --         -9%      -46%      -59%      -61%
# found5at139 132044/s       56%       54%       45%         25%         10%          --      -41%      -55%      -57%
# found7at1   223418/s      164%      160%      146%        112%         86%         69%        --      -24%      -28%
# found6at2   292104/s      245%      240%      222%        177%        143%        121%       31%        --       -6%
# found5at3   310395/s      267%      261%      242%        195%        158%        135%       39%        6%        --

Edit: Ist eventuell ein Perl Problem: https://forum.fhem.de/index.php/topic,84372.0.html https://forum.fhem.de/index.php?topic=88291.0

perl -v
This is perl 5, version 28, subversion 1 (v5.28.1) built for arm-linux-gnueabihf-thread-multi-64int

Bei mir: This is perl 5, version 24, subversion 1 (v5.24.1) built for arm-linux-gnueabihf-thread-multi-64int Das Problem tritt aber auch auf einem anderen Rechner auf, auf dem m.E. das neueste Debian installiert ist.

Ich kenne jetzt das Konzept SignalDuino -> RFFHEM gar nicht, kann also aktuell nichts konkreteres beitragen. Gibt es irgendwo eine Doku, die das beschreibt?

Nicht wirklich - @sidey79 liest du mit?

docolli commented 3 years ago

Der Raspi ist bis auf FHEM nur eine Basisinstallation. Backups sind keine eingerichtet (sollte ich wirklich mal machen 😊). Darum keine Ahnung was da heute morgen passiert ist. Hier der weitere Verlauf bis jetzt:

grafik

Zur Vervollständigung mein System:

lsb_release -a
No LSB modules are available.
Distributor ID: Raspbian
Description:    Raspbian GNU/Linux 10 (buster)
Release:        10
Codename:       buster

Der FHEM Thread ist 60 Seiten lang, darin habe ich folgendes gefunden: https://forum.fhem.de/index.php/topic,84372.msg1142992.html#msg1142992

von rudolfkoenig: 5.24 ist bekannt fuer ein Speicherloch in der Regexp-Bibliothek.
Bevor ich mit der Prozedur im vorherigen Absatz anfangen wuerde, wuerde ich eine andere Perl-Version installieren, entweder durch OS-Upgrade oder durch perlbrew.

Wenn du 5.24 im EInsatz hast und die Verabeitung der Nachrichten per Regexp läuft, dann wäre dies ein testenswerter Ansatz.

docolli commented 3 years ago

Ich lese mich gerade ein bischen in die Source von RFFHEM ein. Die Verarbeitung von "start" läuft in 00_SignalDuino.pm ab Zeile 2572 bis 2594. Suche per index() bzw. substr(). Es deutet nichts auf Regexp hin. Das spricht wieder gegen meinen Ansatz mit einer neueren Perl Version.

Man kann den Signalduino per attribut debug=1 sehr gesprächig machen. Aber das kennt ihr wahrscheinlich schon 😉.

elektron-bbs commented 3 years ago

Würde es dir etwas ausmachen, das System mal 24 Stunden mit deaktivierten Protokoll 111 zu beobachten? Wenn ich die RAM-Belegung bei dir so sehe, werde ich den Verdacht nicht los, das die Sprünge zwischen ca. 100 MB und knapp 600 auch darauf zurück zu führen sind. Bei mir lag die Speicherauslastung vor dem Einbau immer relativ konstant um die 150 MB.

docolli commented 3 years ago

Hab es jetzt deaktiviert. Bin gespannt...

elektron-bbs commented 3 years ago

Danke dir. Hast du FHEM auch neu gestartet? Nur dann wird sofort der Speicher frei gegeben.

docolli commented 3 years ago

Ich habe gestern um 23h noch den "shutdown restart" gemacht. Heute morgen muss ich jedoch feststellen, dass Protokoll 111 im Signalduino wieder aktiv ist! Was mache ich falsch?

docolli commented 3 years ago

Ich habe eben noch das sysmon reading "fhemuptime" ergänzt: grafik

Startet hier meine FHEM Instanz immer wieder neu?

Edit: Tatsächlich, im Log kann ich das nachvollziehen! Leider gibt das Log keine Hinweise auf Ursachen vor dem Neustart. Jetzt wäre ess wirklich spannend was passiert, wenn ich das Protokoll 111 (oder auch noch das 110) deaktiviere,

Mir fällt gerade auf, dass ich das attribut "development" noch auf "1" stehen habe. Macht das was aus?