Alternative culfw

duke-f · 30 Oktober 2019, 12:48:24

Ich habe nochmal etwas mit den Parametern gespielt und durch Beobachtung des CUL das beste Empfangsverhalten im Sinne von am meisten eingegangenen Messages mit folgender Einstellung beobachtet:

Code Auswählen


freq:433.920MHz bWidth:541KHz rAmpl:42dB sens:4dB

Nun konnte ich auch wirklich ein Signal, das am CUL einging und folgende Meldung brachte

Code Auswählen


RAWMSG     omAB4AAAFD

zeitlich sehr sicher dem Omega zuordnen. Dieser reagierte wiederum mit folgender Meldung:

Code Auswählen


state      Code: AD2529B430      2019-10-30 12:36:14

CUL_R_RAWMSG      sAD2529B430FA; 272: 576
CUL_R_TIME            2019-10-30 12:36:14

Weiter meldet der CUL mittlerweile als Clients auch zusätzlich zum CUL_TCM97001 noch OREGON und Hideki, allerdings habe ich dazu keine Device gefunden.
Bin gerne bereit, weitere Tests zu machen oder mehr Infos zu liefern. Im Moment wird der Sensor aber wieder zuverlässig vom RFXtrx empfangen.

freetz · 21 Dezember 2019, 23:10:01

Hallo zusammen,

ich habe von Conrad im Rahmen einer Weihnachtsaktion die Wetterstation Eurochron ETFH-800 gratis mit dazu bekommen, und die ist schon ganz nett, aber ich würde sie gerne in FHEM einbinden, und habe die Hoffnung, da es sich um ein 433MHz-System handelt (s. Foto), dass das vielleicht sogar möglich ist?
Im Forum findet man zu anderen Eurochron-Wetterstationen Hinweise, aber ich bin mir nicht sicher, wie ich eine Einbindung angehen sollte und ob das überhaupt mit diesem Modell out-of-the-box geht. Falls nicht, dann hat vielleicht trotzdem jemand Hinweise, wie ich da vorgehen könnte?

Neben einem zu einem CUL/CUN geflashten Max!Cube (der momentan im Moritz-Modus die Max!-Heizkörper- und Wandthermostate abfragt) hätte ich auch noch einen CC1101-USB-Lite 868MHz Stick hier herumliegen, falls es damit besser/überhaupt nur gehen sollte.

Freue mich über jeden Hinweis, danke dafür schon im Voraus,

F.

cs-online · 22 Dezember 2019, 08:53:29

Hallo,

auf meinen Eurochron-Sensoren steht EFWS 800/801 drauf, die konnte ich mit der alternativem V 1.20.03 a-culfw ganz einfach empfangen und ich meine auch mit der Signalduino-Firmware. War aber nicht sehr zuverlässig, bin dann auch die Technoline auf 868 mhz mit Lacrosse umgestiegen. Was steht auf deinem Sensor/Sender drauf ?

Grüsse Christian

freetz · 22 Dezember 2019, 10:30:12

Hi Christian,

danke für die schnelle Rückmeldung! Auf meinen steht hinten nur EFTH-800 drauf und im Handbuch sind die 433 MHz erwähnt. Die EFWS 800 hatte ich bei der Recherche auch schon gefunden, aber da es sich dabei um 868 MHz Geräte handelt, war ich nicht sicher, ob die da kompatibel sind.
Mir würde es schon reichen, wenn ich die Rohdaten auslesen könnte, dann würde ich versuchen, daraus Sinn zu machen. Geht das irgendwie (problemlos) mit einem umgeflashten Max!Cube oder einem CC1101?

KölnSolar · 22 Dezember 2019, 10:36:42

Scheint ja 433 zu sein....
Guck doch einfach mal, was im Log bei verbose=5 passiert , wenn Du den MaxCube in den slowRF-Modus versetzt.

freetz · 22 Dezember 2019, 11:14:39

Habe ich gemacht, aber es tauchen (bei meinem als CUL umgeflashten Max!Cube) keine Meldungen auf dem Telnet-Port auf, auf dem ich sonst die Rohdaten des Max!-Protokolls sehen kann. Da kommt dann nur in regelmäßigen Abständen:
V 1.26.01 a-culfw Build: private build (unknown) CUBe (F-Band: 868MHz)
Heißt das dann schon mal, dass der Cube ausfällt, weil er nur auf 868Mhz lauscht? Dann müsste ich den CC1101 von Busware noch mal rauskramen...
EDIT: Der CC1101, den ich habe, ist auch ein 868 MHz-Modell. Habe aber gelesen, dass die sich im slowRF-Modus selber auf 433 MHz stellen, ist das korrekt, d.h., könnte ich mit dem Cube weiter testen (habe vielleicht nur nicht lange genug gewartet)?

cs-online · 22 Dezember 2019, 13:28:24

Zitat von: freetz am 22 Dezember 2019, 10:30:12
Hi Christian,

danke für die schnelle Rückmeldung! Auf meinen steht hinten nur EFTH-800 drauf und im Handbuch sind die 433 MHz erwähnt. Die EFWS 800 hatte ich bei der Recherche auch schon gefunden, aber da es sich dabei um 868 MHz Geräte handelt, war ich nicht sicher, ob die da kompatibel sind.
Mir würde es schon reichen, wenn ich die Rohdaten auslesen könnte, dann würde ich versuchen, daraus Sinn zu machen. Geht das irgendwie (problemlos) mit einem umgeflashten Max!Cube oder einem CC1101?

Nee. meine EFWS800 sind Sender, die auf 433Mhz senden und mit einem z.B. NanoCul mit CC1101 mit der angesprochenen Alternativfirmware empfangen werden können (und ich meine auch mit der Signalduino-FW wäre das Dinge empfangbar gewesen)... Evtl. haben die beiden ja die gleichen Protokolle ?

Grüße

Christian

KölnSolar · 22 Dezember 2019, 13:31:49

Ah, auch nur 868. Das geht natürlich nicht.

ZitatHabe aber gelesen, dass die sich im slowRF-Modus selber auf 433 MHz stellen,

Glaub ich so nicht. Das gilt nur für das Senden von IT.
Stell mal die Freq. auf 433.92 und dann im Log gucken. Der868-cc1101 hat zwar bei 433.92 einen schlechteren Empfang aber vielleicht klappt's ja.

freetz · 22 Dezember 2019, 13:36:23

Ah, ok - mit welchem Befehl setze ich denn die Frequenz auf 433,92 MHz? Hier finde ich jedenfalls nichts dazu:
http://culfw.de/commandref.html

KölnSolar · 22 Dezember 2019, 13:39:50

über FHEM beim CUL: set... freq 433.92

cs-online · 22 Dezember 2019, 13:40:47

...normalerweise mit

Code Auswählen

set <Device> freq 433.920

freetz · 22 Dezember 2019, 14:10:02

Prima, danke!
Damit kriege ich auf der Konsole jetzt Nachrichten wie diese hier:

Code Auswählen

V 1.26.01 a-culfw Build: private build (unknown) CUBe (F-Band: 433MHz)
omAA0000000002003A
omAA00003FFFFFFB3A
omAA9C63184A4700F1
omAA000000000FFF80F1
V 1.26.01 a-culfw Build: private build (unknown) CUBe (F-Band: 433MHz)
omAA00000FFFFFFC0C
omAA0000000000000B
omAA7FF43FE00000F4
omAA00000001FFFFF3
V 1.26.01 a-culfw Build: private build (unknown) CUBe (F-Band: 433MHz)
omAA8B329E04F06F800B
omAA000001FFE0000B
omAA00600003FFFF3A
omAA00000000003F3A
omA9F14FF319FE00EA

Das dürften dann wohl keine MAX! Nachrichten mehr sein, oder? Gibt es zu den Eurochron Geräten irgendwo eine Analyse des Protokolls?

freetz · 22 Dezember 2019, 14:12:16

Und im FHEM Log steht auszugsweise zu einer der Telegramme folgendes:

Code Auswählen

2019.12.22 14:04:52 5: CUL/RAW: /omAA23FFFFC0002000F2
omAA000000000000F2

2019.12.22 14:04:52 4: CUL_Parse: CUL_CUBE omAA23FFFFC0002000F2
2019.12.22 14:04:52 5: CUL_CUBE: dispatch omAA23FFFFC0002000F2
2019.12.22 14:04:52 5: CUL_REDIRECT (mAA23FFFFC0002000F2) length: 19 RSSI: -81
2019.12.22 14:04:52 5: CUL_REDIRECT (mAA23FFFFC0002000F2) match Manchester COODE length: 19
2019.12.22 14:04:52 5: CUL_REDIRECT decode Oregon 2 (AA23FFFFC0002000F2)
2019.12.22 14:04:52 5: bitdata: 101010100010001111111111111111111100000000000000001000000000000011110010
2019.12.22 14:04:52 5: CUL_REDIRECT decode Oregon 3 (AA23FFFFC0002000F2)
2019.12.22 14:04:52 5: bitdata: 101010100010001111111111111111111100000000000000001000000000000011110010
2019.12.22 14:04:52 5: CUL_REDIRECT decode Hideki (AA23FFFFC0002000F2)
2019.12.22 14:04:52 5: CUL_CUBE: search in 101010100010001111111111111111111100000000000000001000000000000011110010 

2019.12.22 14:04:52 5: protocol does not match, ignore received package (AA23FFFFC0002000F2) Reason: Not a hideki protocol

Also irgendwie scheint etwas erkannt zu werden, aber dann auch wieder nicht?

KölnSolar · 22 Dezember 2019, 14:49:18

das allgemeine Manchester wird erkannt. Ist aber in seiner Codierung kein der culfw bekanntes.

Mit autocreate wird nichts angelegt ?
Dann müsstest Du das Protokoll selber analysieren. Am einfachsten geht das sicherlich mit einem nanoCUL als S'duino geflashed.

freetz · 22 Dezember 2019, 16:02:29

Ok, danke, autocreate ist aktiv, aber FHEM legt nichts an, vielleicht, weil ich das bestehende CUL device von Max auf slowRF (und die Frequenz) umgestellt habe, anstatt das alte zu löschen? Ansonsten schaue ich mal, ob ich den Telegrammen etwas entlocken kann, mich wundert nur, dass von den drei Sendern hier im Haus nur jedes fünfte nicht nur größtenteils aus Nullen oder FF besteht...