Hallo zusammen.
Ich möchte gerne die Conrad Wetterstation KW 9110 (433 MHz) als Display für Temperatur und Feuchtigkeit von diversen anderen Sensoren benutzen.
Stelle mir das so vor:
Kanal 1 zeigt Aussentemperatur von einem Homemeatic Aussenfühler an
Kanal 2 zeigt mir eine Netatmo Station mit Temperatur/Feuchtigkeit an
Kanal 3 zeigt mir die max. Temperaturvorhersage vom nächsten Tag an (via ProPlanta)
Ich habe einen funktionierenden Signalduino und der dazugehörige Sender wird auch dekodiert. So weit so gut.
Wie mache ich jetzt am geschicktesten weiter? Die Übertragung geht nachher mit einem at, kein Problem. Aber wie bekomme ich die Werte über den Signalduino an die Wetterstation? Mit sendMsg? Gibt es schon ein Lösungsansatz, der in diese Richtung geht?
Habe damals 433 Conrad Steckdosen mit dem RAW Befehl beschickt, aber da brauchte ich auch immer nur 2 unterschiedliche Bitfolgen. Lösung siehe hier: https://forum.fhem.de/index.php/topic,12286.15.html (https://forum.fhem.de/index.php/topic,12286.15.html) Hier funktioniert das aber nicht so einfach.
Gruß und Danke für den Input.
Rainer
OK, ich werde wieder etwas konkreter 8)
Der dazugehörige Sensor hat die Bezeichnung KW9010 und wird auch als solcher vom Signalduino erkannt.
Ebenso die Luftfeuchte und die Temperatur wird korrekt ausgelesen.
Die Events sehen so aus:
2018-11-26 17:04:08.428 CUL_TCM97001 KW9010_39 temperature: 21.5
2018-11-26 17:04:08.428 CUL_TCM97001 KW9010_39 T: 21.5 H: 46
2018-11-26 17:04:40.407 CUL_TCM97001 KW9010_39 temperature: 21.4
2018-11-26 17:04:40.407 CUL_TCM97001 KW9010_39 T: 21.4 H: 46
2018-11-26 17:06:16.415 CUL_TCM97001 KW9010_39 temperature: 21.3
2018-11-26 17:06:16.415 CUL_TCM97001 KW9010_39 T: 21.3 H: 46
2018-11-26 17:06:48.417 CUL_TCM97001 KW9010_39 temperature: 21.2
2018-11-26 17:06:48.417 CUL_TCM97001 KW9010_39 T: 21.2 H: 46
Das Log sieht mit verbose 5 so aus:
2018.11.26 17:10:32.036 4: sduino433/msg READredu: MU;P0=-602;P1=470;P2=-1972;P3=-4058;P4=124;P5=-128;D=0121313131212131213121212131213131212121212131213121210450;CP=1;e;
2018.11.26 17:10:32.037 4: sduino433: Fingerprint for MU Protocol id 13.1 -> FLAMINGO FA21 b matches, trying to demodulate
2018.11.26 17:10:32.037 5: sduino433: start pattern for MU Protocol id 13.1 -> FLAMINGO FA21 b mismatches, aborting
2018.11.26 17:10:32.037 5: sduino433: applying filterfunc SIGNALduino_filterSign
2018.11.26 17:10:32.037 4: sduino433: Fingerprint for MU Protocol id 27 -> remote27 matches, trying to demodulate
2018.11.26 17:10:32.037 5: sduino433: start pattern for MU Protocol id 27 -> remote27 mismatches, aborting
2018.11.26 17:10:32.037 4: sduino433: Fingerprint for MU Protocol id 28 -> IC Ledspot matches, trying to demodulate
2018.11.26 17:10:32.037 5: sduino433: start pattern for MU Protocol id 28 -> IC Ledspot mismatches, aborting
2018.11.26 17:10:32.037 4: sduino433: Fingerprint for MU Protocol id 30 -> unitec47031 matches, trying to demodulate
2018.11.26 17:10:32.037 5: sduino433: start pattern for MU Protocol id 30 -> unitec47031 mismatches, aborting
2018.11.26 17:10:32.037 4: sduino433: Fingerprint for MU Protocol id 36 -> socket36 matches, trying to demodulate
2018.11.26 17:10:32.038 5: sduino433: start pattern for MU Protocol id 36 -> socket36 mismatches, aborting
2018.11.26 17:10:32.038 5: sduino433: applying filterfunc SIGNALduino_compPattern
2018.11.26 17:10:32.038 4: sduino433: Fingerprint for MU Protocol id 39 -> X10 Protocol matches, trying to demodulate
2018.11.26 17:10:32.038 5: sduino433: start pattern for MU Protocol id 39 -> X10 Protocol mismatches, aborting
2018.11.26 17:10:32.038 4: sduino433: Fingerprint for MU Protocol id 45 -> Revolt matches, trying to demodulate
2018.11.26 17:10:32.038 5: sduino433: start pattern for MU Protocol id 45 -> Revolt mismatches, aborting
2018.11.26 17:10:32.038 4: sduino433: Fingerprint for MU Protocol id 61 -> FS10 matches, trying to demodulate
2018.11.26 17:10:32.038 5: sduino433: Starting demodulation at Position 53
2018.11.26 17:10:32.038 4: sduino433: Fingerprint for MU Protocol id 70 -> FHT80TF matches, trying to demodulate
2018.11.26 17:10:32.039 5: sduino433: Starting demodulation at Position 53
2018.11.26 17:10:32.039 4: sduino433: Fingerprint for MU Protocol id 72 -> Siro shutter matches, trying to demodulate
2018.11.26 17:10:32.039 5: sduino433: start pattern for MU Protocol id 72 -> Siro shutter mismatches, aborting
2018.11.26 17:10:32.039 4: sduino433: Fingerprint for MU Protocol id 8 -> TX3 Protocol matches, trying to demodulate
2018.11.26 17:10:32.039 5: sduino433: Starting demodulation at Position 53
2018.11.26 17:10:32.485 4: sduino433/msg READredu: MS;P1=463;P2=-4056;P3=-1978;P4=-8937;D=214131312131312121213131213121313131213121213131313131213121313121213121312;CP=1;SP=4;O;m=0;
2018.11.26 17:10:32.485 4: sduino433: Matched MS Protocol id 0 -> weather1
2018.11.26 17:10:32.485 5: sduino433: Starting demodulation at Position 3
2018.11.26 17:10:32.486 4: sduino433: Decoded MS Protocol id 0 dmsg s2728B0535000 length 40
2018.11.26 17:10:32.486 5: sduino433 Dispatch: s2728B0535000, test gleich
2018.11.26 17:10:32.486 5: sduino433 Dispatch: s2728B0535000, dispatch
2018.11.26 17:10:32.486 5: sduino433: dispatch s2728B0535000
2018.11.26 17:10:32.487 5: sduino433: KW9010 CRC Matched: (010011100100000111010000101011001010000000000000)
2018.11.26 17:10:32.487 5: sduino433: KW9010 CRC Hex Matched: 4e41d0aca000
2018.11.26 17:10:32.487 5: sduino433: KW9010 values are matching
2018.11.26 17:10:32.487 4: sduino433: CUL_TCM97001 using longid: 1 model: KW9010
2018.11.26 17:10:32.489 4: sduino433: Matched MS Protocol id 68 -> PFR-130
2018.11.26 17:10:32.489 5: sduino433: Starting demodulation at Position 3
2018.11.26 17:10:32.489 4: sduino433: Decoded MS Protocol id 68 dmsg s2728B0535000 length 40
2018.11.26 17:10:32.489 5: sduino433 Dispatch: s2728B0535000, test gleich
2018.11.26 17:10:32.489 4: sduino433 Dispatch: s2728B0535000, Dropped due to short time or equal msg
2018.11.26 17:10:32.629 4: sduino433/msg READredu: MS;P1=463;P2=-4059;P3=-1977;P4=-8938;D=14131312131312121213131213121313131213121213131313131213121313121213121312;CP=1;SP=4;O;m=1;
2018.11.26 17:10:32.630 4: sduino433: Matched MS Protocol id 0 -> weather1
2018.11.26 17:10:32.630 5: sduino433: Starting demodulation at Position 2
2018.11.26 17:10:32.630 4: sduino433: Decoded MS Protocol id 0 dmsg s2728B0535000 length 40
2018.11.26 17:10:32.630 5: sduino433 Dispatch: s2728B0535000, test gleich
2018.11.26 17:10:32.630 4: sduino433 Dispatch: s2728B0535000, Dropped due to short time or equal msg
2018.11.26 17:10:32.631 4: sduino433: Matched MS Protocol id 68 -> PFR-130
2018.11.26 17:10:32.631 5: sduino433: Starting demodulation at Position 2
2018.11.26 17:10:32.632 4: sduino433: Decoded MS Protocol id 68 dmsg s2728B0535000 length 40
2018.11.26 17:10:32.632 5: sduino433 Dispatch: s2728B0535000, test gleich
2018.11.26 17:10:32.632 4: sduino433 Dispatch: s2728B0535000, Dropped due to short time or equal msg
2018.11.26 17:10:32.734 4: sduino433/msg READredu: MS;P1=463;P2=-4069;P3=-1980;P4=-8939;D=14131312131312121213131213121313131213121213131313131213121313121213121312;CP=1;SP=4;p;m=2;
2018.11.26 17:10:32.734 4: sduino433: Matched MS Protocol id 0 -> weather1
2018.11.26 17:10:32.734 5: sduino433: Starting demodulation at Position 2
2018.11.26 17:10:32.734 4: sduino433: Decoded MS Protocol id 0 dmsg s2728B0535000 length 40
2018.11.26 17:10:32.734 5: sduino433 Dispatch: s2728B0535000, test gleich
2018.11.26 17:10:32.734 4: sduino433 Dispatch: s2728B0535000, Dropped due to short time or equal msg
2018.11.26 17:10:32.734 4: sduino433: Matched MS Protocol id 68 -> PFR-130
2018.11.26 17:10:32.734 5: sduino433: Starting demodulation at Position 2
2018.11.26 17:10:32.734 4: sduino433: Decoded MS Protocol id 68 dmsg s2728B0535000 length 40
2018.11.26 17:10:32.734 5: sduino433 Dispatch: s2728B0535000, test gleich
2018.11.26 17:10:32.734 4: sduino433 Dispatch: s2728B0535000, Dropped due to short time or equal msg
2018.11.26 17:10:32.744 4: sduino433/msg READredu: MS;P1=463;P2=-4069;P3=-1980;P4=-8939;D=14131312131312121213131213121313131213121213131313131213121313121213121312;CP=1;SP=4;p;m=3;
2018.11.26 17:10:32.744 4: sduino433: Matched MS Protocol id 0 -> weather1
2018.11.26 17:10:32.744 5: sduino433: Starting demodulation at Position 2
2018.11.26 17:10:32.744 4: sduino433: Decoded MS Protocol id 0 dmsg s2728B0535000 length 40
2018.11.26 17:10:32.744 5: sduino433 Dispatch: s2728B0535000, test gleich
2018.11.26 17:10:32.744 4: sduino433 Dispatch: s2728B0535000, Dropped due to short time or equal msg
2018.11.26 17:10:32.744 4: sduino433: Matched MS Protocol id 68 -> PFR-130
2018.11.26 17:10:32.744 5: sduino433: Starting demodulation at Position 2
2018.11.26 17:10:32.744 4: sduino433: Decoded MS Protocol id 68 dmsg s2728B0535000 length 40
2018.11.26 17:10:32.744 5: sduino433 Dispatch: s2728B0535000, test gleich
2018.11.26 17:10:32.744 4: sduino433 Dispatch: s2728B0535000, Dropped due to short time or equal msg
2018.11.26 17:10:32.909 4: sduino433/msg READredu: MU;P0=-1144;P1=-8932;P2=344;P3=464;P4=-4053;P5=-1977;P7=116;D=70353434353435343135353435353434343535343520;CP=3;e;
2018.11.26 17:10:32.910 4: sduino433: Fingerprint for MU Protocol id 13.1 -> FLAMINGO FA21 b matches, trying to demodulate
2018.11.26 17:10:32.910 5: sduino433: start pattern for MU Protocol id 13.1 -> FLAMINGO FA21 b mismatches, aborting
2018.11.26 17:10:32.910 5: sduino433: applying filterfunc SIGNALduino_filterSign
2018.11.26 17:10:32.911 4: sduino433: Fingerprint for MU Protocol id 20 -> livolo matches, trying to demodulate
2018.11.26 17:10:32.911 5: sduino433: Starting demodulation at Position 1
2018.11.26 17:10:32.912 4: sduino433: Fingerprint for MU Protocol id 28 -> IC Ledspot matches, trying to demodulate
2018.11.26 17:10:32.912 5: sduino433: start pattern for MU Protocol id 28 -> IC Ledspot mismatches, aborting
2018.11.26 17:10:32.912 5: sduino433: applying filterfunc SIGNALduino_compPattern
2018.11.26 17:10:32.913 4: sduino433: Fingerprint for MU Protocol id 39 -> X10 Protocol matches, trying to demodulate
2018.11.26 17:10:32.913 5: sduino433: start pattern for MU Protocol id 39 -> X10 Protocol mismatches, aborting
Ich weiss ja jetzt, dass das ganze mit dem "KW 9010" funktioniert. Wie bekomme ich denn jetzt eine Aussendung hin mit beliebigen Temperaturen/Luftfeuchtigkeiten?
Probieren würde ich es so:
set sduino sendMsg P0#xxxxxxx#R3
Aber die Bitfolge, die dazwischen muss, ist mir noch schleierhaft. Ist mein Ansatz richtig?
Gruß Rainer
Hi,
Prinzipiell ist dein Ansatz richtig.
Damit Du die richtige Bitfolge findest, müsstest Du die Werte in das zu senden die Protokoll umrechnen.
Schau dir im CUL_TCM97001 Modul an, wie das Protokoll aufgebaut ist.
Am besten schreibst Du dir eine kleine Perl Funktion, die aus den übergebenen Werten die zu senden Bits errechnet.
Grüße Sidey
Gesendet von meinem Moto Z (2) mit Tapatalk
Hallo Sidey, hallo Forum,
vielen Dank für die Antwort. Bin jetzt soweit, dass ich weiss, dass die kompletten 36Bit in meinem Falle die "x"e aus meinem ersten Post sind.
Leider funktioniert das noch nicht ganz, da der Wert für P0 zu klein ist. Der steht angegeben mit 500ms.
Meine Messungen haben aber 1000ms ergeben. Alle anderen Werte stimmen.
Folgende RAW Aussendung funktioniert:
set sduino433 raw SR;R=6;P1=1000;P2=-2000;P3=-4000;P4=-9000;D=14121313121313131312121213121313131312131312121212131213131312131312131212;
Weißt Du oder sonst jemand, ob das ein Fehler im Modul ist?
Gibt es ein anderes Protokoll, welches diese Werte hat?
Aber irgendetwas an dem Log stimmt ja dann auch nicht. Die Werte werden richtig dekodiert, aber auch da steht ja im Log P0 auf 500, sehr seltsam!
Wer bringt Licht ins Dunkel?
Gruß Rainer
Hallo Forum,
werde mir ein Stück weit mal selber antworten. ::)
Mittlerweile habe ich eine funktionierende Lösung (ab heute, 02.12.2018, im Dauer-Testbetrieb).
Da sich für das Protokoll-Problem noch keine Lösung gefunden hat, habe ich meine Perl-Funktion in der 99_myUtils erweitert, um eine Raw-Signal-Ausgabe zu erhalten (anstatt der eigentlichen Bitfolge). Wenn einer ein funktionierendes Protokoll hat, dann her damit, ich bin immer noch interessiert daran. Dann würde ich meine Funktion nämlich anpassen.
Das, was mir noch fehlt:
- der Temperaturtrend ist noch nicht mit eingebunden (da weiß ich noch nicht, wie ich das in den Vorsystemen realisiere, aussenden könnte ich es schon)
- Batteriebit ist nicht mit eingebunden (da das aber eh keine Rolle spielt, da es in dem Fall keine leere Batterie gibt!)
- Forcesend ist nicht mit eingebunden (macht auch genau so wenig Sinn)
Sieht aber schon alles prima aus. Falls Interesse besteht, kann ich daraus ein Wiki-Artikel machen.
Gruß Rainer
Hallo zusammen,
nach einiger Zeit des Produktiveinsatzes hier noch 2 Anmerkungen:
- Durch den Einbau der Werte von Proplanta kann die Wetterstation keine Vorhersage mehr machen. Es ist halt ein Unterschied, ob nur IST-Temperaturen zur Verfügung stehen oder auch 2 Werte aus der Zukunft dabei sind.
EDIT: Eventuell ändert sich jetzt etwas an der Vorhersage, da ich ab sofort den Temperaturtrend mit auswerte. - Die Wetterstation zeigt keine Luftfeuchte unter 5% an. Macht ja auch Sinn. Da auf dem 3. Kanal aber meine Vorhersage mit der Regenwahrscheinlichkeit liegt, kann diese dann auch nicht kleiner als 5% werden. Auch verschmerzbar.
Ansonsten bin ich mit der Lösung zufrieden, läuft extrem stabil, keine Ausfälle.
Gruß Rainer
Hallo,
den Temp. Trend könntest du mit dem Statistik Modul von FHEM von deinem Temp-Sensor ermitteln.
Gruß Rolf
Hi,
Ich habe mir dein Thema wieder Mal angesehen.
Das Protokoll welches Du da sendest ist das Protokoll mit der ID 0.
Damit wird es auch empfangen.
Grüße Sidey
Gesendet von meinem Moto Z (2) mit Tapatalk
Zitat von: rvideobaer am 20 Januar 2019, 16:09:08
Hallo,
den Temp. Trend könntest du mit dem Statistik Modul von FHEM von deinem Temp-Sensor ermitteln.
Gruß Rolf
Super Idee, habe ich erweitert und umgesetzt, das funktioniert schon mal. Vielleicht kommt da auch dann noch mal eine andere Vorhersage raus ;D
Danke für den Hinweis.
Gruß Rainer
Zitat von: Sidey am 20 Januar 2019, 16:53:37
Hi,
Ich habe mir dein Thema wieder Mal angesehen.
Das Protokoll welches Du da sendest ist das Protokoll mit der ID 0.
Damit wird es auch empfangen.
Grüße Sidey
Gesendet von meinem Moto Z (2) mit Tapatalk
Hallo Sidey,
hat sich denn in Richtung Signalduino irgendetwas geändert oder gab es Ergänzungen? Ansonsten habe ich ja immer noch das Problem aus Post #3, der korrekte Empfang funktioniert bei mir nur mit P1=1000.
Gruß Rainer
Hi,
Ich bin nicht sicher, was Du mit P1=1000 meinst.
Mit Px=<WERT> wird festgelegt, was sich hinter dem Index (x) befindet.
Das zu sendende Signal wird durch die Folge der Indizes (x) definiert.
SR;P0=1000;D=0000;
Führt zu genau dem gleichen Signal wie
SR;P1=1000;1111;
Konkret wird dabei ein 5000uS langes Signal gesendet.
Mit Verbose 4 kannst Du im Log sehen, welche Signalfolge sendMsg erzeugt.
Wenn Du deinen selbst zusammen gebauten RAW Befehl postest und dazu noch die Bitfolge, welche Du sendest können wir schauen ob es einen Unterschied gibt.
Grüße Sidey
Gesendet von meinem Moto Z (2) mit Tapatalk
Zitat von: Sidey am 25 Januar 2019, 07:54:05
Hi,
Ich bin nicht sicher, was Du mit P1=1000 meinst.
Mit Px=<WERT> wird festgelegt, was sich hinter dem Index (x) befindet.
Das zu sendende Signal wird durch die Folge der Indizes (x) definiert.
SR;P0=1000;D=0000;
Führt zu genau dem gleichen Signal wie
SR;P1=1000;1111;
Konkret wird dabei ein 5000uS langes Signal gesendet.
Mit Verbose 4 kannst Du im Log sehen, welche Signalfolge sendMsg erzeugt.
Wenn Du deinen selbst zusammen gebauten RAW Befehl postest und dazu noch die Bitfolge, welche Du sendest können wir schauen ob es einen Unterschied gibt.
Hallo Sidey,
dann wollen wir mal:
Bei Deinem Beispiel käme ich auf 4000µs, und es fehlt noch ein D= in der 2. Zeile, ansonsten leuchtet es mir ein. Das schiebe ich mal auf Flüchtigkeitsfehler. Egal.
Hier gibt es erst einmal eine gültige Bitfolge:
100101000010110111000000100110111100Daraus bastel ich mir dann folgenden RAW-Code-Befehl:
set sduino433 raw SR;;R=6;;P1=1000;;P2=-2000;;P3=-4000;;P4=-9000;;D=14131212131213121212121312131312131313121212121212131212131312131313131212;;Der funktioniert auch perfekt.
Der Unterschied zum vorhandenen Protokoll ist die doppelte Länge des Startbits (in meinem Fall P1=1000, im Protokoll P0=500)
Damit funktioniert der sendMsg Befehl bei mir leider nicht (bzw. der Empfang).
Der Befehl sollte doch so aussehen:
set sduino433 sendMsg P0#100101000010110111000000100110111100#R6oder liege ich da falsch?
Hoffe, meine Ausführungen waren jetzt konkreter, damit Du was damit anfangen kannst.
Gruß Rainer
Zitat von: dora71 am 25 Januar 2019, 15:48:12
Daraus bastel ich mir dann folgenden RAW-Code-Befehl:
set sduino433 raw SR;;R=6;;P1=1000;;P2=-2000;;P3=-4000;;P4=-9000;;D=14131212131213121212121312131312131313121212121212131212131312131313131212;;
Der funktioniert auch perfekt.
Ok verstehe.
Zitat von: dora71 am 25 Januar 2019, 15:48:12
Der Unterschied zum vorhandenen Protokoll ist die doppelte Länge des Startbits (in meinem Fall P1=1000, im Protokoll P0=500)
Ich denke Du meinst die Sync. Jetzt wirds komisch. Das passt nicht zu dem von mir definiteren "Sync" Signal. Genau da passt aber das Protokoll 0 rein.
Zitat von: dora71 am 25 Januar 2019, 15:48:12
set sduino433 sendMsg P0#100101000010110111000000100110111100#R6
oder liege ich da falsch?
Protokoll 0 hat keine voreingestellte Taktrate. Also muss diese noch mitgegeben werden:
set sduino433 sendMsg P0#100101000010110111000000100110111100#R6#C500Langsam verstehe ich mehr :) Danke für die Erklärungen.
Irgendwas passt aber bei deinen Ausführungen und meinem Wissen nicht zusammen.
Das was Du sendest, kann nicht als Protokoll 0 bei einem Empfänger interpretiert werden denke ich. Der Empfänger scheint da aber wohl ziemlich kulant zu sein :)
Mich würde mal interessieren, was empfängst Du wenn ein Sensor etwas sendet.
und welche Version der Firmware verwendest Du?
Ich nochmal ...
also, zuerst mal zum Signalduino:
version: V 3.3.2.1-rc4 SIGNALduino cc1101 - compiled at Sep 29 2018 00:13:24
versionmodul: v3.3.2ralf_11.09.
Den Sensor konnte ich bis dato noch nicht wieder anflanschen.
Habe aber jetzt nochmal ein wenig herumgespielt, und siehe da, es funktioniert mit dem von Dir geschriebenen Code.
Die ersten Tests sehen allerdings so aus, als ob diese etwas unzuverlässiger sind als die RAW-Aussendungen.
Das mit der Taktrate habe ich nicht gewusst, und auch nicht so ganz verstanden. Daher auch nie in Tests eingebaut. Kannst Du mir sagen, warum die ausgerechnet 500 sein muß (was? µs?) Und warum brauche ich die nicht bei der RAW-Aussendung?
Wenn es so funktioniert habe ich im FHEM natürlich weniger Code, das ist erfreulich, ansonsten habe ich ja noch den Fallback!
Ich beobachte mal etwas länger jetzt und melde mich wieder.
Gruß Rainer
2018.11.26 17:10:32.485 4: sduino433/msg READredu: MS;P1=463;P2=-4056;P3=-1978;P4=-8937;D=214131312131312121213131213121313131213121213131313131213121313121213121312;CP=1;SP=4;O;m=0;
2018.11.26 17:10:32.485 4: sduino433: Matched MS Protocol id 0 -> weather1
2018.11.26 17:10:32.485 5: sduino433: Starting demodulation at Position 3
2018.11.26 17:10:32.486 4: sduino433: Decoded MS Protocol id 0 dmsg s2728B0535000 length 40
2018.11.26 17:10:32.486 5: sduino433: dispatch s2728B0535000
2018.11.26 17:10:32.487 5: sduino433: KW9010 CRC Matched: (010011100100000111010000101011001010000000000000)
Ich habe mal nach der Ursache gesucht, warum der KW9010 nicht mehr funktioniert, die Ursache ist dieser Patch:
https://github.com/RFD-FHEM/RFFHEM/commit/8f8af1a111f84bb16cb490d9ba0849332057d26e
Da wurde was in der Definition der ID 0 angepasst
Wenn Du in der "signalduino_protocols.hash" bei der ID 0
bei one die -7 in -8 änderst
und bei zero die -3 in -4 änderst, müsste es wieder funktionieren
"0" => ## various weather sensors (500 | 9100)
{
name => 'weather (v1)',
comment => 'temperature / humidity or other sensors',
id => '0',
knownFreqs => '433.92',
one => [1,-8],
zero => [1,-4],
sync => [1,-16],
clockabs => -1,
format => 'twostate', # not used now
preamble => 's', # prepend to converted message
postamble => '00', # Append to converted message
clientmodule => 'CUL_TCM97001',
#modulematch => '^s[A-Fa-f0-9]+',
length_min => '24',
length_max => '40',
paddingbits => '8', # pad up to 8 bits, default is 4
},
Gruß Ralf
Zitat von: dora71 am 26 Januar 2019, 13:40:19
Den Sensor konnte ich bis dato noch nicht wieder anflanschen.
Hallo Ralf,
da habe ich mich wohl etwas missverständlich ausgedrückt ... ich meinte das mehr hardwaretechnisch (den Sensor habe ich nicht mehr aus der Kiste ausgepackt und versucht, ihn mit FHEM einzulesen) ... dass es damit tatsächlich Probleme gab/gibt, war mir nicht bewusst. Das ist ja jetzt echt ein Zufall :o zur Zeit benutze ich den Sensor auch gar nicht (mehr), mir ist es wichtig, die Wetterstation / Anzeige für meine Zwecke zu "erweitern".
Ich denke aber, dass der auch nach wie vor funktionieren wird, da ja jetzt die "neue Aussendemethode" mit sendMsg auch funktioniert.
Witzigerweise ändern sich seitdem auch wieder die Vorhersagesymbole ??? ob die allerdings richtig sind, kann ich noch nicht beurteilen.
Gruß Rainer
Zitatja jetzt die "neue Aussendemethode" mit sendMsg auch funktioniert.
Bitte teste mal ob es mit der ID 0.3 genausogut funktioniert:
set sduino433 sendMsg P0.3#100101000010110111000000100110111100#R6#C500Gruß Ralf
Hallo Ralf,
0.3 scheint mein System nicht zu kennen. Schreibfehler oder bin ich nicht aktuell genug?
set sduino433 sendMsg P0.3#100111000000011110000000011001011101#R6#C500 : sduino433: sendmsg, unknown protocol: 0.3
Gruß Rainer
Du bist anscheinend nicht aktuell genug, die ID 0.3 gibt es seit dem 19.12.
In der protocollist kannst Du sehen ob es die 0.3 bei Dir gibt.
Entweder "get protocollist" oder im Information menu "Display protocollist"
Die aktuelle bekommst Du damit
update all https://raw.githubusercontent.com/RFD-FHEM/RFFHEM/dev-r33/controls_signalduino.txt
Gruß Ralf
Hallo Ralf,
habe Deinen Update-Befehl eingefügt, bin aber jetzt am schwimmen, da ich noch in Erinnerung habe, dass ich die FHEM/00_SIGNALduino.pm vom Update ausgeschlossen hatte.
Meine Konstellation ist zur Zeit wie folgt:
version V 3.3.2.1-rc4 SIGNALduino cc1101 - compiled at Sep 29 2018 00:13:24
versionmodul v3.3.2ralf_11.09.
Außerdem sagt er mir beim Update, dass es eine neue Firmware gibt.
Wie ist jetzt am besten das weitere Vorgehen, denn trotz Deines Update-Befehls zeigt er mir nicht das Protokoll 0.3 an (wegen Firmware?).
Soll ich alles updaten und die "Original 00_SIGNALduino.pm" wieder mit einbeziehen?
Gruß Rainer
Du kannst mit
update all https://raw.githubusercontent.com/RFD-FHEM/RFFHEM/dev-r33/controls_signalduino.txt
updaten und die 00_SIGNALduino.pm mit aktualisieren.
Versionmodul ist aktuell: "v3.3.3-dev_30.12."
Gruß Ralf
Hallo Ralf,
das Update hat funktioniert 8) und es läuft mit der Protokollversion 0.3. Witzigerweise konnte der KW9110, als ich "nur" 2 der 3 möglichen Temperaturanzeigen mit Protokoll 0.3 augesendet hatte (die 3. war noch auf Protokoll 0 gestellt), damit nicht (mehr) umgehen. Oder es kam vom Update.
Wie auch immer, mit 0.3 läuft es. Danke @alle für die Hilfe.
PS: Seit dem Update empfange ich jetzt andere ganz interessante (?!) Sender. Was hat es denn mit den 55,7 auf sich, ist das ein "Übersetzungsfehler"? Die Sender sind auf jeden Fall nicht von mir.
ABS700_2 T: 8.5
ABS700_3 T: 55.7
ABS700_4 T: 8.5
ABS700_6 T: 8.5
TCM97..._0 T: 55.7
TCM97..._1 T: 55.7
TCM97..._5 T: 55.7
Unknown Code: 0378B5
Gruß Rainer
Hallo Rainer,
ich bin gerade dabei auch den KW9015 in das 14_CUL_TCM97001.pm Modul einzubauen.
Ich könnte dazu von Deinem KW9010 noch ein paar Nachrichten gebrauchen, sie sehen ungefähr so aus:
READredu: MS;P1=463;P2=-4056;P3=-1978;P4=-8937;D=214131312131312121213131213121313131213121213131313131213121313121213121312;CP=1;SP=4;O;m=0;
Decoded MS Protocol id 0.3 dmsg s2728B0535000 length 40
Wie viele Kanale hat der KW9010?
Evtl lässt sich der KW9010 und der KW9015 (immer Kanal 0?) über den Kanal unterscheiden
Ich könnte folgende Nachrichten gebrauchen mit Angabe ob die Batterien voll oder leer sind.
Für jeden Kanal eine Nachricht.
Eine Nachricht mit gedrückter Tx Taste
Bei einer Nachricht auch mit Angabe vom Temp und Hum
Gruß Ralf
Hallo Ralf,
ich benutze schon seit gefühlten Ewigkeiten den Sender der Wetterstation nicht mehr.
Vielmehr benutze verschiedene Werte aus FHEM (Kanal 1: Homematic Außensensor, Kanal 2: Garagentemperatur und Luftfeuchte über MQTT eingespeist und Kanal 3 ist die Vorhersage von Proplanta) und lasse mir die an der Wetterstation anzeigen.
Soweit ich mich erinnern kann, hatte der Sender auch 3 Kanäle.
Falls es Dir etwas nützt, kann ich Dir meine selber zusammengefrickelte Funktion, über die ich die Wetterstation beschicke, zukommen lassen. Nützt Dir das etwas? Da solltest Du doch alle Infos herausbekommen mit.
Gruß Rainer
ZitatFalls es Dir etwas nützt, kann ich Dir meine selber zusammengefrickelte Funktion, über die ich die Wetterstation beschicke, zukommen lassen. Nützt Dir das etwas? Da solltest Du doch alle Infos herausbekommen mit.
Ich möchte mir Deine Funktion gerne anschauen.
Du kannst Sie mir per email schicken oder hier posten.
Gruß Ralf
Hallo Ralf,
ich stelle die Funktion hier gerne zur Verfügung. Meine bescheidenen Programmierkenntnisse in Perl möge man mir verzeihen. Untergebracht ist die Funktion in der myUtils.
Einiges habe ich kommentiert in der Hoffnung, dass ich mich später wieder dran erinnern kann.
Hoffentlich kannst Du etwas davon brauchen. Die letzten Zeilen habe ich seit längerem auskommentiert, da das Protokoll vom Signalduino schon erkannt wurde und übernommen werden konnte.
Ein Aufruf, der auf Kanal 3 das ProPlanta Wetter für morgen setzt, sieht z. B. folgendermaßen aus:
{fhem("set sduino433 sendMsg P0.3#".KW9010bits(ReadingsNum('WetterProplanta','fc1_tempMax',0),ReadingsNum('WetterProplanta','fc1_chOfRainDay',10),3,0)."#R6#C500")}
Gruß Rainer
sub KW9010bits($$$$) {
my ($temp, $hum, $kanal, $trendinput) = @_;
# Sicherheitsabfragen, damit nur gültige Werte dargestellt werden
if ($temp > 75.0) {
$temp = 75.0;
}
if ($hum > 99) {
$hum = 99;
}
elsif ($hum < 5) {
$hum = 5;
}
if ($kanal < 1 || $kanal > 3) {
$kanal = 3;
}
# Log 1, "KW9010-Werte: ".$temp." ".$hum." ".$kanal." ".$trendinput;
my $tempfinal = $temp*10;
my $humfinal = $hum+156;
my $forcedsend = "0"; # Bit 12
my $trend = "00"; # Bit 10-11, Voreinstellung: Tendenz gleichbleibend
if ($trendinput > 0) {
$trend = "01"; # Tendenz steigend
}
if ($trendinput < 0) {
$trend = "10"; # Tendenz fallend
}
my $bat = "0"; # Bit 9, Batterie ok == 0
my $beginn1 = "1001"; # Random-ID Part1, Bits 1-4
my $beginn2 = "00"; # Random-ID Part2, Bits 7-8
my $bintemp = "";
if ($tempfinal >= 0) {
$bintemp = reverse sprintf "%012b", $tempfinal;
}
elsif ($tempfinal < 0) {
$bintemp = substr((reverse sprintf "%b", $tempfinal),0,12);
#print "Negative Temperatur - binär: ".substr($bintemp,0,12);
}
my $binhum = reverse sprintf "%08b", $humfinal;
my $prefinal = $beginn1.sprintf("%02b", $kanal).$beginn2.$bat.$trend.$forcedsend.$bintemp.$binhum;
my $checksum = "0";
# Checksumme berechnen: Halbbytes rückwärts addieren, Ergebnis invertieren
for (my $i=0; $i < length $prefinal; $i++) {
if (($i+1) % 4 == 0) {
$checksum += substr($prefinal,$i,1)*8;
}
elsif (($i+1) % 4 == 1) {
$checksum += substr($prefinal,$i,1);
}
elsif (($i+1) % 4 == 2) {
$checksum += substr($prefinal,$i,1)*2;
}
elsif (($i+1) % 4 == 3) {
$checksum += substr($prefinal,$i,1)*4;
}
#print "i = $i, Checksumme = $checksum\n";
}
my $checksumfinal = reverse sprintf "%04b", $checksum % 16;
my $finalbincode = $prefinal.$checksumfinal;
# hier würde der reine Binärcode zurückgegeben
# Log 1, "Binärcode: ".$finalbincode;
return $finalbincode;
# weitere Umsetzung für die RAW-Aussendung mit Signalduino,
# falls das Protokoll mal irgendwann stimmt, kann dieser Schritt entfallen
# Pulslänge: P1=1000ms, P2=-2000ms, P3=-4000ms, P4=-9000ms
# "0" = P1P2, "1" = P1P3, Startbit = P1P4, ist aber im RAW Command drin
#my $finalrawcode = "";
#for (my $i=0; $i < length $finalbincode; $i++) {
# if (substr($finalbincode,$i,1) eq "0") {
# $finalrawcode .= "12";
# }
# elsif (substr($finalbincode,$i,1) eq "1") {
# $finalrawcode .= "13";
# }
# }
# Log 1, "RAW-Code: ".$finalrawcode;
# return $finalrawcode;
}
Hallo Rainer,
danke, damit kann ich mir die gewünschten Nachrichten selbst erzeugen, bis auf den Trend ist nun alles klar.
if ($trendinput > 0) {
$trend = "01"; # Tendenz steigend
}
if ($trendinput < 0) {
$trend = "10"; # Tendenz fallend
}
Kannst Du bitte mal nachprüfen was bei $trendinput = 1 (steigend) und was bei $trendinput = -1 (fallend) auf der Wetterstation angezeigt wird
Gruß Ralf
Hallo Ralf,
ZitatKannst Du bitte mal nachprüfen was bei $trendinput = 1 (steigend) und was bei $trendinput = -1 (fallend) auf der Wetterstation angezeigt wird
bei $trendinput = 1 wird auf der Wetterstation unter der Temperaturanzeige ein Pfeil von unten links nach oben rechts dargestellt
bei $trendinput = -1 wird auf der Wetterstation unter der Temperaturanzeige ein Pfeil von oben links nach unten rechts dargestellt
wenn die beiden Bits auf 0 stehen, wird ein waagerechter Pfeil angezeigt.
Es gibt auch noch eine Trendanzeige für die Luftfeuchte, ebenfalls als Pfeil dargestellt. Da habe ich aber bis heute nicht rausgefunden, ob das auch über die Funktelegramme kommt oder ob die Wetterstation das intern bildet. Eigentlich sind laut Protokoll schon alle Bits belegt.
Da sich dieser Pfeil aber bei mir ändert trotz gleich bleibenden Funktelegrammen, denke ich, letzteres ist der Fall.
Hoffe, ich konnte helfen.
Gruß Rainer