SIGNALDuino Oregon Sensoren

RappaSan · 30 Dezember 2016, 10:33:20

Nö, ob's da ist oder nicht - kein Unterschied.

Sidey · 30 Dezember 2016, 10:35:12

Ich wüsste gerade nicht, wie man das im Modul implementiert oder eben nicht..

Ralf9 · 30 Dezember 2016, 10:48:41

Liegt es evtl daran, daß das event über DoTrigger und nicht über readingsEndUpdate erzeugt wird?

Sidey · 30 Dezember 2016, 11:11:40

Ich habe mir den Code angesehen... Es liegt daran, dass Willi direkt in die Variablen Reading die Werte geschrieben hat und nicht mit Reading Update gearbeitet hat.

Das sollte sich leicht lösen lassen.

Bezüglich Maintainer hat sich niemand gemeldet, ich werde es dann formal übernehmen.

Sidey · 31 Dezember 2016, 00:30:02

Ich habe das 41_Oregon angepasst:

Code Auswählen

update all https://raw.githubusercontent.com/RFD-FHEM/RFFHEM/dev-r33/controls_signalduino.txt

Habe es mit einem Temperatursensor bei mir getestet und es funktioniert meiner Meinung nach.

Grüße Sidey

Sidey · 31 Dezember 2016, 01:11:11

@Ralf

ich habe mal ein Patch erstellt um das 41_Oregon zwischen FHEM Update und unserem git zu vergleichen

Du hast dort einen Sensor entfernt, funktioniert der wirklich nicht oder können wir den wieder aufnehmen?

Grüße Sidey

Ralf9 · 31 Dezember 2016, 02:20:05

Du meinst wahrscheinlich diese beiden Sensoren

Code Auswählen


   OREGON_type_length_key(0x3a0d, 80) =>

   # RGR126, RGR682, RGR918:
   OREGON_type_length_key(0x2a1d, 80) =>

Durch meine Anpassung werden bei den beiden Sensoren auch die Nachrichtenlängen 84 und 88 berücksichtigt. Dadurch sind die beiden gelöschten Sensoren mit den doppelten Ids nicht mehr notwendig

Gruß Ralf

Sidey · 31 Dezember 2016, 14:52:03

Ich meine den WGR918. Wird der durch rgr918 ersetzt?

Ralf9 · 31 Dezember 2016, 15:06:13

Zitat von: Sidey am 31 Dezember 2016, 14:52:03
Ich meine den WGR918. Wird der durch rgr918 ersetzt?

Der ist doch in Zeile 201 drin

Code Auswählen

part => 'WGR918', checksum => \&OREGON_checksum4, method => \&OREGON_wgr918_anemometer,

Sidey · 31 Dezember 2016, 15:31:19

OK, habe ich auf dem Handy übersehen

RappaSan · 01 Januar 2017, 10:29:54

Ein "Frohes neues Jahr" in die Runde.

Kleine Rückmeldung: event-min-interval funktioniert nach Sidey's patch bei mir.

Sequenzial · 07 Januar 2017, 18:20:57

Moin,

bin etwas verwirrt (kommt schon mal vor, aber diesmal ist es was technisches;-) ):

Ich habe im Dezember 2016 eine WH5300 Wetterstation gekauft und diese wurde vom SignalDuino als CTW600 erkannt:

Code Auswählen

Internals: 
   CODE       CTW600 
   DEF        CTW600 
   NAME       CTW600 
   NR         223 
   STATE      Defined 
   TYPE       SD_WS09 
   bitMSG 
   lastMSG 
   Readings: 
     2017-01-05 20:52:51   battery         4 
     2017-01-05 20:52:51   humidity        64 
     2017-01-05 20:52:51   id              41 
     2017-01-05 20:52:51   rain            27.9 
     2017-01-05 20:52:51   state           T: -4.7  H: 64  Ws: 0.0  Wg: 0.0  Wd: W  R: 27.9 
     2017-01-05 20:52:51   temperature     -4.7 
     2017-01-05 20:52:51   windDirection   12 
     2017-01-05 20:52:51   windDirectionDegree 270 
     2017-01-05 20:52:51   windDirectionText W 
     2017-01-05 20:52:51   windGust        0.0 
     2017-01-05 20:52:51   windSpeed       0.0 
Attributes: 
   alias      WH5300 
   icon       WH5300 
   room       21-SignalDuino RX6B,22-SignalDuino CC1101,Garten 
   showtime   1 
   stateFormat temperature °C

Lief über meherere Wochen einwandfrei (mit dem RSSI Wert -78).
Dann am 5.1.2017 kamen plötzlich keine neuen Werte mehr an.

Stattdessen hat FHEM eine WH1080 erkannt und angelegt (Status "defined", aber es kommen auch keine Werte an).

Im Log sehe ich, dass nun ein Protokoll id 10 (ich denke das fällt in die Oregon Sparte) erkannt wird

Code Auswählen

2017.01.07 15:34:02 4 : SingalDuino.cc1101: Found manchester Protocol id 10 clock 329 -> OSV2o3
Aber ein entsprechendes Device wird nicht erstellt.

Und neu sind die Protokolle mit den ids 20+29+40+57 ...

ID 29 (HT12e remote)
Das id 29 - Gerät können wir, glaube ich aussen vor lassen, weil das vom RSSI Wert eher bei den Nachbarn steht:

Code Auswählen

2017.01.07 17:16:44 4 : SingalDuino.cc1101: decoded matched MU Protocol id 29 dmsg u29#000 length 12 RSSI = -82.5
2017.01.07 17:16:44 4 : SIGNALduino_unknown incomming msg: u29#000
2017.01.07 17:16:44 4 : SIGNALduino_unknown rawData: 000
2017.01.07 17:16:44 4 : SIGNALduino_unknown Protocol: 29
2017.01.07 17:16:44 4 : SIGNALduino_unknown converted to bits: 000000000000
2017.01.07 17:16:44 4 : Unknown, please report
2017-01-07 17:16:44 SIGNALduino SingalDuino.cc1101 UNKNOWNCODE u29#000
2017.01.07 17:16:44 3 : SingalDuino.cc1101: Unknown code u29#000, help me!

&

ID 40 (romotec)
sagt mir überhaupt nichts, ist aber vom Empfangswert (RSSI) gleich der Wetterstation:

Code Auswählen

2017.01.07 17:22:09 4 : SingalDuino.cc1101: decoded matched MU Protocol id 40 dmsg u40#28423CF7385 length 44 RSSI = -78
2017-01-07 17:22:09 SIGNALduino SingalDuino.cc1101 opened
2017.01.07 17:22:09 4 : SIGNALduino_unknown incomming msg: u40#28423CF7385
2017.01.07 17:22:09 4 : SIGNALduino_unknown rawData: 28423CF7385
2017.01.07 17:22:09 4 : SIGNALduino_unknown Protocol: 40
2017.01.07 17:22:09 4 : SIGNALduino_unknown converted to bits: 00101000010000100011110011110111001110000101
2017.01.07 17:22:09 4 : Unknown, please report
2017-01-07 17:22:09 SIGNALduino SingalDuino.cc1101 UNKNOWNCODE u40#28423CF7385
2017.01.07 17:22:09 3 : SingalDuino.cc1101: Unknown code u40#28423CF7385, help me!

&

ID 20 (livolo)
sagt mir überhaupt nichts, ist aber vom Empfangswert (RSSI) gleich der Wetterstation:

Code Auswählen

2017.01.07 17:22:10 4 : SingalDuino.cc1101: decoded matched MU Protocol id 20 dmsg u20#FFFFFF length 24 RSSI = -78
2017.01.07 17:22:10 4 : SIGNALduino_unknown incomming msg: u20#FFFFFF
2017.01.07 17:22:10 4 : SIGNALduino_unknown rawData: FFFFFF
2017.01.07 17:22:10 4 : SIGNALduino_unknown Protocol: 20
2017.01.07 17:22:10 4 : SIGNALduino_unknown converted to bits: 111111111111111111111111
2017.01.07 17:22:10 4 : Unknown, please report
2017-01-07 17:22:10 SIGNALduino SingalDuino.cc1101 UNKNOWNCODE u20#FFFFFF
2017.01.07 17:22:10 3 : SingalDuino.cc1101: Unknown code u20#FFFFFF, help me!

&

ID 57 (m-e)
sagt mir überhaupt nichts, ist aber vom Empfangswert (RSSI) gleich der Wetterstation

Code Auswählen

2017.01.07 17:22:10 4 : SingalDuino.cc1101: Found manchester Protocol id 57 clock 339 RSSI -78 -> m-e
2017.01.07 17:22:10 4 : SIGNALduino_unknown incomming msg: u57#420AA2801520
2017.01.07 17:22:10 4 : SIGNALduino_unknown rawData: 420AA2801520
2017.01.07 17:22:10 4 : SIGNALduino_unknown Protocol: 57
2017.01.07 17:22:10 4 : SIGNALduino_unknown converted to bits: 010000100000101010100010100000000001010100100000
2017.01.07 17:22:10 4 : Unknown, please report
2017-01-07 17:22:10 SIGNALduino SingalDuino.cc1101 UNKNOWNCODE u57#420AA2801520
2017.01.07 17:22:10 3 : SingalDuino.cc1101: Unknown code u57#420AA2801520, help me!

Diese Geräte/Protokolle hat es vor dem 5.1.2017, meiner Meinung, nach noch nicht im Log gegeben.

Was noch komisch ist, dass das Protokoll id 10 nur eine einzige Zeile auswirft:

Code Auswählen

2017.01.07 15:34:02 4 : SingalDuino.cc1101: Found manchester Protocol id 10 clock 329 -> OSV2o3

Die anderen sind immer mehrzeiler mit decodier versuchen.

Verbose ist auf 4
In der Anlage hab ich noch mal ein komplettes Log über 30 Minuten angefügt.

update all https://raw.githubusercontent.com/RFD-FHEM/RFFHEM/dev-r33/controls_signalduino.txt
hatte ich heute (7.1.2017) um ~16:30 gemacht.

Steh nun irgendwie auf dem Schlauch.

Gruß
Seq

Ralf9 · 07 Januar 2017, 21:03:42

Zitat von: Sequenzial am 07 Januar 2017, 18:20:57
Ich habe im Dezember 2016 eine WH5300 Wetterstation gekauft und diese wurde vom SignalDuino als CTW600 erkannt:

Dies passt zu diesem Thema nicht so richtig, da es hier um Oregon Sensoren geht.

Wenn ein Oregon Sensor erkannt wird, dann steht im log auch noch die folgende Zeile:

Code Auswählen

sduino: OSV2 protocol detected: preamble_pos = 33

Wird die WH5300 von dem sduino mit dem RX6B erkannt?

Gruß Ralf

Sequenzial · 08 Januar 2017, 00:14:48

Hi,

Zitat von: Ralf9 am 07 Januar 2017, 21:03:42
Dies passt zu diesem Thema nicht so richtig, da es hier um Oregon Sensoren geht.

Wenn ein Oregon Sensor erkannt wird, dann steht im log auch noch die folgende Zeile:
Code Auswählen Erweitern
sduino: OSV2 protocol detected: preamble_pos = 33

hmm, was mich hierher getrieben hat war halt die Protokoll ID 10

Code Auswählen

2017.01.07 15:34:02 4 : SingalDuino.cc1101: Found manchester Protocol id 10 clock 329 -> OSV2o3
was ich erstmal als Oregon interpretiert habe.
Wo wäre ich damit denn besser aufgehoben?
Ich war über die SignalDuino Entwicklung 3.3.1 hier her "gestolpert".

Zitat
Wird die WH5300 von dem sduino mit dem RX6B erkannt?

ja ... hmm ...
cc1101 abgezogen und den RX6B dran gehängt.
Hab im Attachment mal das Debug Log + Verbose 4 gehängt (und diesmal auf SignalDuino gefiltert)
Der empfängt schon was, aber so richtig schlau was er empfängt werde ich nicht aus dem Log.

Aber irgendwie kommt mir das unvollständig vor

Code Auswählen

2017.01.07 23:29:03 4 : SingalDuino.rx6b/msg READ: MU;P0=-973;P1=1446;P3=450;P4=684;P5=-232;P6=1088;D=01010101010101010101030101010101045301010106;CP=1;
2017.01.07 23:29:03 1 : DEBUG>SingalDuino.rx6b: incomming message: (MU;P0=-973;P1=1446;P3=450;P4=684;P5=-232;P6=1088;D=01010101010101010101030101010101045301010106;CP=1;)
2017.01.07 23:29:03 1 : DEBUG>SingalDuino.rx6b: extracted pattern 0 -973
2017.01.07 23:29:03 1 : DEBUG>SingalDuino.rx6b: extracted pattern 1 1446
2017.01.07 23:29:03 1 : DEBUG>SingalDuino.rx6b: extracted pattern 3 450
2017.01.07 23:29:03 1 : DEBUG>SingalDuino.rx6b: extracted pattern 4 684
2017.01.07 23:29:03 1 : DEBUG>SingalDuino.rx6b: extracted pattern 5 -232
2017.01.07 23:29:03 1 : DEBUG>SingalDuino.rx6b: extracted pattern 6 1088
2017.01.07 23:29:03 1 : DEBUG>SingalDuino.rx6b: extracted data 01010101010101010101030101010101045301010106
2017.01.07 23:29:03 1 : DEBUG>SingalDuino.rx6b: extracted clockidx 1
2017.01.07 23:29:03 1 : DEBUG>SingalDuino.rx6b: processing unsynced message
2017.01.07 23:29:03 1 : DEBUG>Testing against Protocol id [...]

Rest -> Attachment

Es kommt meiner Meinung nach keine abschließende Meldung das ein decodieren (via Protokoll ID) möglich war oder eben nicht...
Der cc1101 sagt zumindest, dass er damit nichts anfangen kann.

Die Empfangseinheit von der Wetterstation bekommt ihre Daten noch einwandfrei,
insofern gehe ich davon aus, dass an der Quelle der Fehler nicht liegt.

Ich werde die Wetterstation noch mal komplett "resetten" und die angelegten Devices aus der fhem.cfg löschen.

Aber du hast schon recht, dass ich bei den Oregons nicht richtig bin.
Werde hier einen neuen Versuch starten:
FHEM Forum » CUL » Hard- und Firmware » günstige Wetterstation CTW-600, WS-0101, WS/WH1080 sduino

(bitte ggf. die letzten Posts von mir hier raus nehmen)

Danke erst mal!

Gruß
Seq

RappaSan · 13 April 2017, 19:20:36

Zitat von: Ralf9 am 29 Dezember 2016, 20:28:03
Hallo,

hier gibt es Probleme mit dem event-min-interval beim Oregon Modul, ich ging eigentlich davon aus, daß es funktioniert
https://forum.fhem.de/index.php/topic,63643.msg548842.html#msg548842

Funktioniert bei euch das event-min-interval beim Oregon Modul?

Gruß Ralf

So ein Modul mit diesem Fehler gibt's noch:

Internals:
CFGFN
CODE SD_WS07_TH_1
DEF SD_WS07_TH_1
LASTInputDev sduino
MSGCNT 6
NAME SD_WS07_TH_1
NR 333
STATE T: 12.6 H: 58
TYPE SD_WS07
bitMSG 10110101 1 000 000001111110 1111 00111010
lastMSG B5807EF3A
lastReceive 1492105063
sduino_DMSG P7#B5807EF3A
sduino_MSGCNT 6
sduino_RAWMSG MS;P4=-3867;P5=467;P6=-1989;P7=-997;D=54565756565756575656575757575757575756565656565657565656565757565656575657;CP=5;SP=4;O;
sduino_TIME 2017-04-13 19:37:43
Readings:
2017-04-13 19:37:43 battery ok
2017-04-13 19:37:43 channel 1
2017-04-13 19:37:43 humidity 58
2017-04-13 19:37:43 state T: 12.6 H: 58
2017-04-13 19:37:43 temperature 12.6
Attributes:
event-min-interval .*:300
event-on-change-reading .*
room Autocreated

Das Attribut event-min-interval spielt keine Rolle, hier wird ein event ca. alle 20 Sekunden ausgelöst.