FSK mit dem SIGNALDuino

Begonnen von Ralf9, 22 Dezember 2019, 17:30:36

Vorheriges Thema - Nächstes Thema

Reinhard.M

Danke für die schnelle Rückmeldung!
Ich habe bereit model=WH65B gewählt. Temperatur, Humidity und Windrichtung scheinen weitestgehend zu stimmen. Auch der UV Werte sieht eigentlich gut aus. Der Lux Wert ist mal ca. Faktor 10 zu hoch und Regen sowie Windstärken absolut daneben. Hier mal aktuelle Daten vom Sensor:
Zitat2023-03-09_12:37:55 SD_WS_204 T: 11.9 H: 62 Ws: 6.4 Wg: 9.7 Wd: W Lux: 678740 UV: 4 R: 15111.8
2023-03-09_12:37:55 SD_WS_204 temperature: 11.9
2023-03-09_12:37:55 SD_WS_204 humidity: 62
2023-03-09_12:37:55 SD_WS_204 windSpeed: 6.4
2023-03-09_12:37:55 SD_WS_204 windSpeed_kmh: 360.0
2023-03-09_12:37:55 SD_WS_204 windDirectionDegree: 272
2023-03-09_12:37:55 SD_WS_204 windDirectionText: W
2023-03-09_12:37:55 SD_WS_204 windGust: 9.7
2023-03-09_12:37:55 SD_WS_204 windGust_kmh: 34.9
2023-03-09_12:37:55 SD_WS_204 batteryState: low
2023-03-09_12:37:55 SD_WS_204 rain: 2651.0
2023-03-09_12:37:55 SD_WS_204 rain_total: 15111.8
2023-03-09_12:37:55 SD_WS_204 uv: 4
2023-03-09_12:37:55 SD_WS_204 lux: 678740
2023-03-09_12:37:55 SD_WS_204 id: 05

Und über den WiFi Zugang:
Zitat2023-03-09_12:37:33.080 WH4000SE israining: 0
2023-03-09_12:37:55.676 WH4000SE windspeed: 20.2
2023-03-09_12:37:55.734 WH4000SE rain_week: 13.5
2023-03-09_12:37:55.734 WH4000SE wind_chill_f: 53.4
2023-03-09_12:37:55.734 WH4000SE wind_gust_mps: 7.1
2023-03-09_12:37:55.734 WH4000SE wind_speed: 15.8
2023-03-09_12:37:55.734 WH4000SE rain_month: 13.5
2023-03-09_12:37:55.734 WH4000SE indoorTemperature: 22.3
2023-03-09_12:37:55.734 WH4000SE pressure: 1001.6
2023-03-09_12:37:55.734 WH4000SE indoorHumidity: 39
2023-03-09_12:37:55.734 WH4000SE rain_year: 86.4
2023-03-09_12:37:55.734 WH4000SE wind_chill: 11.9
2023-03-09_12:37:55.734 WH4000SE rain: 0.0
2023-03-09_12:37:55.734 WH4000SE wind_speed_mps: 4.4
2023-03-09_12:37:55.734 WH4000SE dewpoint: 4.6
2023-03-09_12:37:55.734 WH4000SE wind_direction: 263
2023-03-09_12:37:55.734 WH4000SE wind_speed_mph: 9.8
2023-03-09_12:37:55.734 WH4000SE wind_gust: 25.6
2023-03-09_12:37:55.734 WH4000SE humidity: 61
2023-03-09_12:37:55.734 WH4000SE rain_day: 9.9
2023-03-09_12:37:55.734 WH4000SE temperature: 11.9
2023-03-09_12:37:55.734 WH4000SE wind_gust_mph: 15.9
2023-03-09_12:37:55.734 WH4000SE luminosity: 70075.2
2023-03-09_12:37:55.734 WH4000SE wind_compasspoint: W
2023-03-09_12:37:55.734 WH4000SE wind_speed_bft: 3
2023-03-09_12:37:55.734 WH4000SE wind_speed_kn: 8.5
2023-03-09_12:37:55.734 WH4000SE wind_speed_fts: 14.4
2023-03-09_12:37:55.734 WH4000SE wind_gust_bft: 4
2023-03-09_12:37:55.734 WH4000SE wind_gust_kn: 13.8
2023-03-09_12:37:55.734 WH4000SE wind_gust_fts: 23.3
2023-03-09_12:37:55.734 WH4000SE wind_gust_direction_avg10m: 276
2023-03-09_12:37:55.734 WH4000SE wind_direction_avg2m: 266
2023-03-09_12:37:55.734 WH4000SE wind_speed_avg2m: 18.0
2023-03-09_12:37:55.734 WH4000SE wind_speed_mph_avg2m: 11.2
2023-03-09_12:37:55.734 WH4000SE wind_speed_kn_avg2m: 9.7
2023-03-09_12:37:55.734 WH4000SE wind_speed_mps_avg2m: 5.0

Ich kann natürlich auch die RAW Message dazu raussuchen, dauert etwas länger.

Gruß Reinhard

Ralf9

ZitatDer Lux Wert ist mal ca. Faktor 10 zu hoch und Regen sowie Windstärken absolut daneben
Wird über Wifi auch Lux angezeigt? Ist es immer um den selben Faktor zu hoch?
Und bei den Windstärken ist es da auch immer um den selben Faktor zu hoch?
Beim Regen sind die absuluten Werte nicht aussagekräftig, Du müsstest Dir mal beim SD_WS_204 und über Wifi das rain merken und dann darauf achten ob es sich bei beiden gleich erhöht
FHEM auf Cubietruck mit Igor-Image, SSD und  hmland + HM-CFG-USB-2,  HMUARTLGW Lan,   HM-LC-Bl1PBU-FM, HM-CC-RT-DN, HM-SEC-SC-2, HM-MOD-Re-8, HM-MOD-Em-8
HM-Wired:  HMW_IO_12_FM, HMW_Sen_SC_12_DR, Selbstbau IO-Module HBW_IO_SW
Maple-SIGNALduino, WH3080,  Hideki, Id 7

Reinhard.M

Hallo Ralf,
der Lux Wert ist im WiFi Faktor 10 kleiner. Ich habe ein paar vergleichbare Werte genommen, scheint konstant zu sein.
Der "rain_total" Wert ist einfach konstant, der rain Wert entspricht dem gesamten bislang gemessenen Niederschlag.
wind_speed wird in m/s ausgegeben und wind_speed_kmh hat den Faktor 55 auf wind_speed.
wind_gust scheint beide Male den richtigen Wert zu zeigen.
UV, Temp und Hum scheinen soweit korrekt zu sein.
Ich hoffe die Werte helfen dir ein wenig, viel kann es ja jetzt nicht mehr sein  ;)
Gruß Reinhard

Ralf9

Ich hab mirs angeschaut.
Bei der ProtocolID 204 ist in der SD_WS noch ein Bug bei Lux (geteilt durch 10 fehlt) und bei wind_speed_kmh. Es gibt demnächst eine neue Version der SD_WS
Das wind_speed in m/s müsste eigentlich passen
Bei rain bitte mal beobachten ob sich bei SD_WS_204 und über Wifi das rain gleich erhöht.
FHEM auf Cubietruck mit Igor-Image, SSD und  hmland + HM-CFG-USB-2,  HMUARTLGW Lan,   HM-LC-Bl1PBU-FM, HM-CC-RT-DN, HM-SEC-SC-2, HM-MOD-Re-8, HM-MOD-Em-8
HM-Wired:  HMW_IO_12_FM, HMW_Sen_SC_12_DR, Selbstbau IO-Module HBW_IO_SW
Maple-SIGNALduino, WH3080,  Hideki, Id 7

Reinhard.M

Hallo Ralf,
das meinte ich mit "entspricht dem gesamten...", mein Fehler. Der Gesamtwert ist um den gleichen Betrag gestiegen wie auch der Tageswert. Immer schön parallel mit jedem Regenschauer der kam. rain entsprich also eigentlich dem rain_total Wert und ist als solcher korrekt. Was fehlt ist der aktuelle Niederschlagswert. Die Wochen-, Monats- und Jahreswerte in der WiFi Übertragung stammen sicherlich von der Basisstation.

Gruß Reinhard

hajo23

Zitat von: Reinhard.M am 10 März 2023, 13:15:55
Hallo Ralf,
das meinte ich mit "entspricht dem gesamten...", mein Fehler. Der Gesamtwert ist um den gleichen Betrag gestiegen wie auch der Tageswert. Immer schön parallel mit jedem Regenschauer der kam. rain entsprich also eigentlich dem rain_total Wert und ist als solcher korrekt. Was fehlt ist der aktuelle Niederschlagswert. Die Wochen-, Monats- und Jahreswerte in der WiFi Übertragung stammen sicherlich von der Basisstation.

Gruß Reinhard

Wenn ich es richtig verstehe, ist das korrekt so. Der Sensor sendet nur "rain". Raintotal soll im Falle eines Ausfalls/Reset/Batteriewechsel des Sensors den letzten Wert halten, um dann damit weiterzählen zu können.

Reinhard.M

Zitat von: hajo23 am 10 März 2023, 18:21:51
Wenn ich es richtig verstehe, ist das korrekt so. Der Sensor sendet nur "rain". Raintotal soll im Falle eines Ausfalls/Reset/Batteriewechsel des Sensors den letzten Wert halten, um dann damit weiterzählen zu können.
Grundsätzlich nicht falsch. Allerdings soll der "rain_total" den Gesamtwert liefern und "rain" den aktuellen Niederschlag. Momentan wird in "rain" der Gesamtwert geführt und in "rain_total" ein etwa 5,7 mal größerer Fantasiewert der sich zwar mit dem "rain" Wert gleichzeitig ändert aber nicht um einen festen Faktor. Momentan (3 verschiedene Messwerte verglichen) liegt der Abstand zwischen rain und rain_total bei 5,697 / 5,698 / 5,699. Der Unterschied sieht zwar gering aus, sollte aber bei einer fixen Umrechnung nicht vorkommen.
@Ralf: Das ich "rain_total" zunächst als fix betrachtet hatte lag wohl an zu wenig Daten. Beide Rain Werte ändern sich gleichzeitig. Allerdings nicht mit konstanten Abstandfaktor.

Ralf9

rain und rain_total sollte sich eigentlich mit gleichem Abstand ändern.
Es gibt ein reading ".rainOffset"
rain_total ist rain + rainOffset

    # rain
    if (defined($rain) && defined(ReadingsVal($name, 'rain', undef))) {
      my $rainOffset = ReadingsVal($name, ".rainOffset", 0);
      my $maxdeviation = AttrVal($name, 'max-deviation-rain', $defaultMaxDeviation);
      if (SD_WS_Sanity_checks($ioname, $name, 'rain', 'rain', $rain, 0, $maxdeviation) == -1) {
        my $valErr = ReadingsVal($name, 'rainErr', undef);
        if (!defined($valErr)) {
          readingsSingleUpdate($hash, 'rainErr', $rain, 0); # fehlerhafte rain merken
          $sanityFlag = 0; # Abbruch
        }
        else {  # die vorherige rain war fehlerhaft -> Differenz zur vorherigen rain pruefen
          if (SD_WS_Sanity_checks($ioname, $name, 'rainErr', 'rainErr', $rain, 0, $maxdeviation) == -1) {
            readingsSingleUpdate($hash, 'rainErr', $rain, 0);
            $sanityFlag = 0; # Abbruch
          }
          else {  # rain ok
            readingsDelete($hash, "rainErr");
            my $lastRain = ReadingsVal($name, "rain", 0);
            # wenn der aktuelle Wert < letzter Wert ist, dann fand ein reset statt
            # die Differenz "letzter Wert - aktueller Wert" wird dann als offset für zukünftige Ausgaben zu rain addiert
            # offset wird auch im Reading ".rain_offset" gespeichert
            if ($rain < $lastRain) {
              $rainOffset += $lastRain;
              readingsSingleUpdate($hash, '.rainOffset', $rainOffset, 0);
              Log3 $hash, 3, "$ioname: $name reset rain, rain: $rain lastrain: $lastRain, new rainOffset: $rainOffset";
            }
          }
        }
      }
      else { # rain ok
        if (defined(ReadingsVal($name, 'rainErr', undef))) {
          readingsDelete($hash, "rainErr");
        }
      }
      $rain_total = $rain + $rainOffset;
    }
    return "" if ($sanityFlag == 0);
FHEM auf Cubietruck mit Igor-Image, SSD und  hmland + HM-CFG-USB-2,  HMUARTLGW Lan,   HM-LC-Bl1PBU-FM, HM-CC-RT-DN, HM-SEC-SC-2, HM-MOD-Re-8, HM-MOD-Em-8
HM-Wired:  HMW_IO_12_FM, HMW_Sen_SC_12_DR, Selbstbau IO-Module HBW_IO_SW
Maple-SIGNALduino, WH3080,  Hideki, Id 7

Reinhard.M

Zitat von: Ralf9 am 12 März 2023, 12:20:08
rain und rain_total sollte sich eigentlich mit gleichem Abstand ändern.
Es gibt ein reading ".rainOffset"
rain_total ist rain + rainOffset
Stimmt, 12460,8. Dann passt es auch das der Quotient sich ändert :)

Ralf9

Es gibt eine neue Version meiner Variante der 14_SD_WS.pm
https://github.com/Ralf9/14_SD_WS/blob/main/FHEM/14_SD_WS.pm
update all https://raw.githubusercontent.com/Ralf9/14_SD_WS/main/controls_ralf9_sd_ws.txt
 - neue ID 123: Inkbird IBS-P01R, ITH-20R (Pool Thermometer)
 - ID 120: BatteryState zugefügt
 - ID 122: update
 - ID 204: bugfix, Lux und windSpeed_kmh

Gruß Ralf
FHEM auf Cubietruck mit Igor-Image, SSD und  hmland + HM-CFG-USB-2,  HMUARTLGW Lan,   HM-LC-Bl1PBU-FM, HM-CC-RT-DN, HM-SEC-SC-2, HM-MOD-Re-8, HM-MOD-Em-8
HM-Wired:  HMW_IO_12_FM, HMW_Sen_SC_12_DR, Selbstbau IO-Module HBW_IO_SW
Maple-SIGNALduino, WH3080,  Hideki, Id 7

Reinhard.M

Hallo Ralf,
Wind und Lux scheinen bei mir erst einmal zu passen, ich werde es weiter beobachten. 

Gruß Reinhard 

Nobbynews

#371
Hallo zusammen,

angestoßen durch die Diskussion hier
https://forum.fhem.de/index.php?topic=134268.msg1286131#msg1286131
möchte ich jetzt doch mal mein Problem/Feststellung schildern.

Ich habe hier im Forum Bodenfeuchtesensoren WH51 erworben und die funktionieren soweit auch gut.

Um FSK empfangen zu können, habe ich mir einen SignalESP mit der Firmware 3.5.1 RC 1 zusammengesteckt.
define SIGNALFSK SIGNALduino 192.168.2.58:23
attr SIGNALFSK hardware esp8266cc1101
attr SIGNALFSK rfmode Fine_Offset_WH51_434
attr SIGNALFSK verbose 4
attr SIGNALFSK whitelist_IDs 107
#   CFGFN     
#   Clients    :CUL_EM:CUL_FHTTK:CUL_TCM97001:CUL_TX:CUL_WS:Dooya:FHT:FLAMINGO:FS10:FS20: :Fernotron:Hideki:IT:KOPP_FC:LaCrosse:OREGON:PCA301:RFXX10REC:Revolt:SD_AS:SD_Rojaflex: :SD_BELL:SD_GT:SD_Keeloq:SD_RSL:SD_UT:SD_WS07:SD_WS09:SD_WS:SD_WS_Maverick:SOMFY: :Siro:SIGNALduino_un:
#   DEF        192.168.2.58:23
#   DMSG       W107#510D48E6107F1B00AA00000010F0
#   DevState   initialized
#   DeviceName 192.168.2.58:23
#   FD         7
#   FUUID      64c4d228-f33f-17d9-6aca-d3da3c1b819a6fb1
#   LASTDMSG   W107#510D48E6107F1B00AA00000010F0
#   LASTDMSGID 107
#   MSGCNT     8
#   NAME       SIGNALFSK
#   NR         47
#   PARTIAL   
#   RAWMSG     MN;D=510D48E6107F1B00AA00000010F0;R=52;
#   RSSI       -48
#   STATE      opened
#   TIME       1690620762.75552
#   TYPE       SIGNALduino
#   cc1101_available 1
#   eventCount 5
#   sendworking 0
#   version    V 3.5.1-RC1 SIGNALESP cc1101 (chip CC1101) - compiled at Jun 18 2023 10:45:20
#   versionProtocols 1.48
#   versionmodul 3.5.5+20230516
#   DoubleMsgIDs:
#   MatchList:

Mit dem originalen SD_WS müssten diese Sensoren ja empfangbar sein. Aus der commandref:
ZitatFine Offset WH51, aka ECOWITT WH51, aka Froggit DP100, aka MISOL/1 (Bodenfeuchtesensor)

Leider bekomme ich damit aber Fehlermeldungen derart:
2023.07.29 10:50:37 4: SIGNALFSK: Read, msg: ␂MN;D=510D48E30F7F2B00E10000007DA0;R=22;␃
2023.07.29 10:50:37 4: SIGNALFSK: Parse_MN, Found 2-FSK Protocol id 107 -> WH51 433.92 MHz with match (?^:^51)
2023.07.29 10:50:37 4: SIGNALFSK: SD_WS_Parse protocol 107, rawData 510D48E30F7F2B00E10000007DA0
2023.07.29 10:50:37 4: SIGNALFSK: SD_WS_Parse 510D48E30F7F2B00E10000007DA0 protocolid 107 (WH51, DP100, MISOL/1) - ERROR prematch
2023.07.29 10:50:39 4: SIGNALFSK: KeepAlive, ok, retry = 0
2023.07.29 10:51:32 4: SIGNALFSK: Read, msg: MN;D=510D48E6107F1B00AA00000010F0;R=53;
2023.07.29 10:51:32 4: SIGNALFSK: Parse_MN, Found 2-FSK Protocol id 107 -> WH51 433.92 MHz with match (?^:^51)
2023.07.29 10:51:32 4: SIGNALFSK: SD_WS_Parse protocol 107, rawData 510D48E6107F1B00AA00000010F0
2023.07.29 10:51:32 4: SIGNALFSK: SD_WS_Parse 510D48E6107F1B00AA00000010F0 protocolid 107 (WH51, DP100, MISOL/1) - ERROR prematch
2023.07.29 10:51:32 4: SIGNALFSK: Read, msg: MN;D=510D48E6107F1B00AA00000010F0;R=53;

Daher habe ich testweise das Modul 14_SD_WS von @Ralf9 genommen und damit geht es einwandfrei.
define FeuchteKraeuter SD_WS SD_WS_107_H_0D48E3
attr FeuchteKraeuter event-min-interval humidity:300,ad:300
attr FeuchteKraeuter event-on-change-reading .*
attr FeuchteKraeuter room XX_Neu
#   CODE       SD_WS_107_H_0D48E3
#   DEF        SD_WS_107_H_0D48E3
#   FUUID      64c017d9-f33f-8873-2d62-ab96bbd86191011e
#   FVERSION   14_SD_WS.pm:0.216660/2023-06-10
#   LASTInputDev SIGNALFSK
#   MSGCNT     20887
#   NAME       FeuchteKraeuter
#   NR         1067
#   SIGNALFSK_DMSG W107#510D48E30F7F2A00DF0000007797
#   SIGNALFSK_MSGCNT 20887
#   SIGNALFSK_Protocol_ID 107
#   SIGNALFSK_RAWMSG MN;D=510D48E30F7F2A00DF0000007797;R=10;
#   SIGNALFSK_RSSI -69
#   SIGNALFSK_TIME 2023-09-06 15:28:44
#   STATE      H: 42 Bv: 1.5
#   TYPE       SD_WS
#   bitMSG     
#   eventCount 6348
#   lastMSG    510D48E30F7F2A00DF0000007797
#   lastReceive 1694006924.61298
#   READINGS:
#     2023-09-06 15:28:44   ad              223
#     2023-09-06 15:28:44   batteryVoltage  1.5
#     2023-09-06 15:28:44   humidity        42
#     2023-09-06 15:28:44   id              0D48E3
#     2023-09-06 15:28:44   state           H: 42 Bv: 1.5
#     2023-09-06 15:28:44   transPerBoost   0
#     2023-09-06 15:28:44   type            WH51
#
setstate FeuchteKraeuter H: 42 Bv: 1.5
setstate FeuchteKraeuter 2023-09-06 15:28:44 ad 223
setstate FeuchteKraeuter 2023-09-06 15:28:44 batteryVoltage 1.5
setstate FeuchteKraeuter 2023-09-06 15:28:44 humidity 42
setstate FeuchteKraeuter 2023-09-06 15:28:44 id 0D48E3
setstate FeuchteKraeuter 2023-09-06 15:28:44 state H: 42 Bv: 1.5
setstate FeuchteKraeuter 2023-09-06 15:28:44 transPerBoost 0
setstate FeuchteKraeuter 2023-09-06 15:28:44 type WH51


14_SD_WS.pm 21666 2023-06-10 10:00:00Z Ralf9
00_SIGNALduino.pm 26977 2023-01-06 11:35:00Z Sidey

Wo ist denn da jetzt mein Denkfehler?
Und wie passt dann
Zitat von: Ralf9 am 06 September 2023, 14:57:38Bei Bedarf könnte ich mein 14_SD_WS Modul so anpassen und ergänzen, daß es auch bei FSK mit dem 00_SIGNALduino Modul von sidey verwendet werden kann.

Gruß
Norbert

Ralf9

#372
Hallo Norbert,

ZitatMit dem originalen SD_WS müssten diese Sensoren ja empfangbar sein. Aus der commandref:
Leider bekomme ich damit aber Fehlermeldungen derart:
Der Grund ist eine regex in der prematch Routine, die nicht für alle Sensoren passt.

Hier sind einige Unterschiede der SD_WS Module von mir und Sidey:

Bei mir wird bei den IDs 107, 116, 207 und 213 die fixeID an die DEF angehängt. Bei Sidey muß da bei Bedarf das sduino Attribut longids gesetzt werden.

Die ID 207 entspricht der ID 117 von Sidey.

Bei Sidey werden bei den ID 115 und 117 die CRC am Anfang auch zum SD_WS übertragen obwohl diese bereits im 00_SIGNALduino Modul berechnet wurden. Bei der ID 108 wird die Prüfsumme am Anfang nicht zum SD_WS übertragen, dies ist nicht ganz einheitlich.
Bei mir wird bei den ID 115 und 207 die CRC am Anfang nicht zum SD_WS übertragen.

Die IDs 211 (Sidey 125) und IDs 213 (Sidey 126) sind nicht kompatibel.
Bei Sidey wird die CRC im SD_WS berechnet
Ich berechne die CRC im 00_SIGNALduino Modul

Gruß Ralf
FHEM auf Cubietruck mit Igor-Image, SSD und  hmland + HM-CFG-USB-2,  HMUARTLGW Lan,   HM-LC-Bl1PBU-FM, HM-CC-RT-DN, HM-SEC-SC-2, HM-MOD-Re-8, HM-MOD-Em-8
HM-Wired:  HMW_IO_12_FM, HMW_Sen_SC_12_DR, Selbstbau IO-Module HBW_IO_SW
Maple-SIGNALduino, WH3080,  Hideki, Id 7

Nobbynews

#373
Hallo Ralf,

dank für die Erläuterungen zu den Unterschieden.

Zitat von: Ralf9 am 06 September 2023, 17:57:20Der Grund ist eine regex in der prematch Routine, die nicht für alle Sensoren passt.
Ist das jetzt Absicht oder ein Bug?
Der WH51 ist ja schließlich als unterstütztes Modell angegeben.
Oder liegt es an einer speziellen Ausführung meiner WH51?

Norbert

Ralf9

#374
Bei den 433 MHz WH51 gibts einige wenige wo sich die Nachrichten ein klein wenig unterscheiden, für diese passt die regex nicht.
Solche Probleme können entstehen, wenn bei einer regex auch Ziffern überprüft werden deren Bedeutung nicht bekannt ist.
FHEM auf Cubietruck mit Igor-Image, SSD und  hmland + HM-CFG-USB-2,  HMUARTLGW Lan,   HM-LC-Bl1PBU-FM, HM-CC-RT-DN, HM-SEC-SC-2, HM-MOD-Re-8, HM-MOD-Em-8
HM-Wired:  HMW_IO_12_FM, HMW_Sen_SC_12_DR, Selbstbau IO-Module HBW_IO_SW
Maple-SIGNALduino, WH3080,  Hideki, Id 7