Signalduino Version 3.3.1 / 3.3.2 / 3.3.3-dev

[viegener]

Ich habe mir ja den Signalduinon-Sketch seit langem nicht angeschaut und habe damals nur die Implementierung im FHEMDuino-Sketch gemacht. Deshalb kann ich über die besonderen Schwierigkeiten beim Signalduino nichts aussagen.

Grundsätzlich klingt es aber richtig, die SW-Sync-Erkennung mit einzubauen (Im FHEMDuino ist auch der HW Sync eingebaut - im CUL wollte ich den HW-Sync auch verwenden, um das Timing anzupassen). Ich hatte bisher angenommen, dass auch andere Ptorokolle entsprechende Syncs einsetzen (als Alternative zur Präambel)

[habeIchVergessen]

Ein Möglichkeit wäre, in die Firmware die Erkennung des Software sync einzubauen. Dazu könnte dann bei Bedarf die für die Erkennung notwendigen Daten ins EEPROM geschrieben werden. Z.B. die Protokoll ID gefolgt von zwei 16 Bit Werten (z.B. 43, 4550, 604)

diese Erkennung sollte implementiert sein (s. hier).

@viegener: eine SOMFY-Nachricht sollte immer mit 0xA beginnen. wenn die führende 0 auftritt, dann sollte 0x5 herauskommen. Das sehe ich bei den geposteten Daten nicht. Somit sollten diese im SOMFY-Modul verworfen werden. richtig? (in meinem alten Fork war es zumindest mal so). Zumindest im SIGNALduino wird nur dispatcht, wenn YsA... empfangen wird.

[Ralf9]

eine SOMFY-Nachricht sollte immer mit 0xA beginnen. wenn die führende 0 auftritt, dann sollte 0x5 herauskommen.

Ja, stimmt das mit dem A hatte ich in der Protokollbeschreibung übersehen.

Key: "Encryption Key", Most significant 4-bit are always 0xA, Least Significant bits is a linear counter. In the Smoove Origin this counter is increased together with the rolling code. But leaving this on a constant value also works. Gerardwr notes that for some other types of remotes the MSB is not constant.

Wenn die SOMFY-Nachricht immer mit 0xA anfängt, dann kann dies als Preamble verwendet werden und damit in der "sub SIGNALduino_SomfyRTS()" die führende 0 entfernt werden
https://github.com/RFD-FHEM/RFFHEM/blob/dev-r33/FHEM/00_SIGNALduino.pm#L4120

Gruß Ralf

[habeIchVergessen]

"SIGNALduino_SomfyRTS()"

sollte nur aufgerufen werden, wenn ein Match bzgl. Protokoll 43 vorliegt, richtigt? Dann würde die Preamble-Erkennung nicht funktionieren.

[Ralf9]

sollte nur aufgerufen werden, wenn ein Match bzgl. Protokoll 43 vorliegt, richtigt?

ja, es wird, wenn es als Protokoll 43 erkannt wird, vor dem dispatch aufgerufen.
Wenn die SOMFY-Nachricht durch eine führende Null mit 5 anfängt, dann kann hier die Null entfernt werden.

Gruß Ralf

[viegener]

@viegener: eine SOMFY-Nachricht sollte immer mit 0xA beginnen. wenn die führende 0 auftritt, dann sollte 0x5 herauskommen. Das sehe ich bei den geposteten Daten nicht. Somit sollten diese im SOMFY-Modul verworfen werden. richtig? (in meinem alten Fork war es zumindest mal so). Zumindest im SIGNALduino wird nur dispatcht, wenn YsA... empfangen wird.

Nein, dieser Teil der Beschreibung unter dem Link ist wohl inkorrekt. Ich habe das ursprünglich auch so implementiert, ich kann aber inzwischen sehen dass das wohl nicht stimmt. Ich habe mehrere Somfy-Fernbedienungen, die auch andere Codes als A am Anfang senden!

Siehe auch Kommentar im Text:

Gerardwr notes that for some other types of remotes the MSB is not constant.

Ich hätte vermutlich erwähnen sollen, dass ich das natürlich in der signalduino-pm bei mir angepasst habe.

[viegener]

ja, es wird, wenn es als Protokoll 43 erkannt wird, vor dem dispatch aufgerufen.
Wenn die SOMFY-Nachricht durch eine führende Null mit 5 anfängt, dann kann hier die Null entfernt werden.

Gruß Ralf

Leider geht das nicht so einfach, da - siehe oben

[habeIchVergessen]

Ich habe mehrere Somfy-Fernbedienungen, die auch andere Codes als A am Anfang senden!

hier würden mich die Nachrichten (exemplarisch als MU-Mitschnitt + Rolling Code + Enc Key) und das Model der FB interessieren.

Es werden "nur" die ersten 4 Bits geändert und der Rest der Nachrichten-Kodierung bleibt gleich?
Was macht ein Rollo, dass auf eine FB mit den ersten 4 Bits != 0xA reagiert, wenn es eine inhaltlich richtige Nachricht beginnend mit 0xA erhält?

Ggf. sollten wir das in einem Somfy-Thread weiterführen!

[viegener]

hier würden mich die Nachrichten (exemplarisch als MU-Mitschnitt + Rolling Code + Enc Key) und das Model der FB interessieren.

Es werden "nur" die ersten 4 Bits geändert und der Rest der Nachrichten-Kodierung bleibt gleich?
Was macht ein Rollo, dass auf eine FB mit den ersten 4 Bits != 0xA reagiert, wenn es eine inhaltlich richtige Nachricht beginnend mit 0xA erhält?

Ggf. sollten wir das in einem Somfy-Thread weiterführen!

Nein es sind ganz normale Fernbeidenungen von Somfy (über 10 Jahre alt und auch ganz neue) und neben dem Encryption Key verändert sich auch der rollingcode.

Der Rolladen reagiert auf 0xA am Anfang und auf welche ohne 0xA am Anfang.

Die Protokollbeschreibung im obigen Link ist einfach an der Stelle inkorrekt. Das erste Nibble ist wohl NICHT fest 0xA

Ich bin nicht sicher ob das in den Somfy-Thread gehört, denn es sind ja 2 Probleme, die beide zum Signalduino gehören:
1) Die feste Einstellung auf 0xA am Anfang ist zu restriktiv und sollte z.B. im Modulematch einfach:

Code Auswählen Erweitern

^Ys[0-9A-F]{14} heissen
2) Es wird beim Somfy-Protokoll (zumindest bei mir) gelegentlich ein 0-bit am Anfang zuviel gelesen

[noxx]

Moin

Hatte hier schon was geschrieben
https://forum.fhem.de/index.php?topic=72807.0
wäre wohl besser hier aufgehoben.

Signalduino empfängt Daten meiner TFA Wetterstation. Temp/Feuchte passt alles.
Bei Wind werden jedoch viel zu hohe Werte angezeigt.

Durch lesen hier im Forum, soll das angeblich m/s sein, was FHEM anzeigt.
Ich lese hier teilweise Werte von 52 (52 m/s -> 187 km/h ? ) während die Basis Werte knapp
über 10 km/h anzeigt.

Code Auswählen Erweitern


Save config
Floorplans
CUL_TX
FHEM
Hardware
LOG
Plots
Pool
SD_WS_Maverick
Schatthaus
Unsorted
Wetterstation
icoEverything Everything
Logfile
Commandref
Remote doc
Edit files
Select style
Event monitor

Internals:
   CFGFN
   CODE       Hideki_12_4
   DEF        Hideki_12_4
   LASTInputDev SignalDuino1
   MSGCNT     41
   NAME       TFA_Wind
   NR         249
   STATE      T: 20.8  Ws: 110  Wg: 81  Wd: SSE
   SignalDuino1_DMSG P12#757EB244F8BEF8BEF00FF82CA30801
   SignalDuino1_MSGCNT 41
   SignalDuino1_RAWMSG MC;LL=-1020;LH=933;SL=-529;SH=446;D=A8E0765DDF060BC182F843FC1CB9D7BC;C=487;L=126;
   SignalDuino1_TIME 2017-06-06 16:51:56
   TYPE       Hideki
   lastMSG    7582d6cc08c208c210110874e51803
   lastReceive 1496760716
   Readings:
     2017-06-06 16:51:56   battery         ok
     2017-06-06 16:51:56   channel         4
     2017-06-06 16:51:56   state           T: 20.8  Ws: 110  Wg: 81  Wd: SSE
     2017-06-06 16:51:56   temperature     20.8
     2017-06-06 16:51:56   windChill       20.8
     2017-06-06 16:51:56   windDirection   7
     2017-06-06 16:51:56   windDirectionDegree 157.5
     2017-06-06 16:51:56   windDirectionText SSE
     2017-06-06 16:51:56   windGust        81
     2017-06-06 16:51:56   windSpeed       110
Attributes:
   event-min-interval .*:300
   event-on-change-reading .*
   room       Wetterstation

Die Basis hägnt an einem WEEWX Server, meine letzen Daten:
Wind   15 km/h SW (234°)

[Ralf9]

Signalduino empfängt Daten meiner TFA Wetterstation. Temp/Feuchte passt alles.
Bei Wind werden jedoch viel zu hohe Werte angezeigt.

ist es der gleiche Windmesser wie hier?
https://github.com/RFD-FHEM/RFFHEM/issues/129

Gruß Ralf

[noxx]

Bis auf die Temperatur  ist eigentlich alles falsch.
Windspeed/Windböen um Faktor 6-7
Windrichtung ebenfalls nicht korrekt (Gerade zeigt Basis W bis SW und FHEM SSO).

[Ralf9]

Für die Windrichtung könnte man so wie beim SD_WS09 Modul ein Attribut für die Windrichtungs Korrektur einbauen.

Für die Windspeed/Windböen gibt es 2 Möglichkeiten, ein fester Korrekturfaktor oder ein Attribut.
Der feste Korrekturfaktor hätte evtl den Nachteil, daß dann bei anderen Wetterstationen die Windspeed/Windböen nicht mehr passt.
Es gibt auch von anderen Herstellern Wetterstationen die das Hideki Protokoll verwenden.

Liest hier jemand mit der auch eine Wetterstation mit dem Hideki Protokoll hat?
Passt dort die Windspeed/Windböen?

Gruß Ralf

[pejonp]

Versucht es einmal mit mph für die Windgeschwindigkeit.

https://de.windfinder.com/wind/windspeed.htm

Pejonp

[noxx]

ist es der gleiche Windmesser wie hier?
https://github.com/RFD-FHEM/RFFHEM/issues/129

Gruß Ralf

Ja, der 30.3168 (mit Solarpanel)

Hab mich auch mal auf der Suche gemacht, evtl kann man davon was gebrauchen

https://github.com/merbanan/rtl_433
https://www.mikrocontroller.net/topic/211884
https://github.com/merbanan/rtl_433/issues/371
https://github.com/merbanan/rtl_433/blob/master/src/devices/hideki.c
https://github.com/pimatic/rfcontroljs/issues/68