Temperatursender von Wetterstation in CUL

[rudolfkoenig]

@nicor2k: und eventTypes ist auch veraltet

[nicor2k]

@rudolfkoenig + @bjoernh:

Oh, das ist mir jetzt unangenehm... Habe also einfach mal "Update" eingegeben, FHEM neugestartet und die Temperatur neu senden lassen, jetzt stimmt sie... Ich wusste gar nicht, dass der Sensor auch die Luftfeuchtigkeit misst, im Display steht nichts davon. Er zeigt allerdings einen etwas hohen Wert an (61), ein anderer Sensor daneben zeigt 20 an. Aber das ignoriere ich erstmal, mir ging es ja um die Temperatur - und das Testen, ob es auch mit so einem günstigen Sensor (halber Preis der Technoline/LaCrosse Sender) klappt.

Vielen Dank nochmal für Eure Hilfe!

[Sidey]

Hi,

ich bin der Meinung der Match Regex stimmte nicht (falsche Länge für manche Sensoren), also habe das mal auf die einfache Art korrigiert, da bereits in der matchlist vom IO Device ja die Nachricht in sofern geprüft wird, ob es sich um HEX Werte handelt. Ich denke das reicht dann so.

Da das Modul nicht nur mit einem CUL läuft, habe ich mir auch erlaubt die Doku etwas anzupassen.


Da ich keinen CUL besitze, wäre es toll wenn das mal jemand ausprobieren würde.

Grüße Sidey

[nicor2k]

Hallo Sidney, teste das gerne aus - wie bekomme ich das Update aber in meine Datei? Nutze bisher einen einfachen Texteditor für FHEM

[Sidey]

Hi,

für das anwenden eines Patches benötigst Du ein entsprechendes Tool:

Zuerst in das geclonte SVN oder GIT Repo Verzeichnis wechseln, danach den Patch anwenden:

Code Auswählen Erweitern


patch -p0 < ~/ 0001-CUL_TCM97001-Updated-match-regex-and-doc.patch



Ich bin eher der GIT Anwender, deshalb nicht getestet.

Quelle:
http://scribu.net/wordpress/svn-patches-from-git.html


Grüße Sidey

[bjoernh]

ich bin der Meinung der Match Regex stimmte nicht (falsche Länge für manche Sensoren), also habe das mal auf die einfache Art korrigiert, da bereits in der matchlist vom IO Device ja die Nachricht in sofern geprüft wird, ob es sich um HEX Werte handelt. Ich denke das reicht dann so.

Ich denke der Regex stimmt
Bei Perl bedeutet . ein Zeichen.
Der String muss also mindestens .... Zeichen haben.
Perl hat dann die Eigenart, dass es nach dieser Festlegung jedes beliebige Zeichen, sowie auch Länge sein kann.
Schöner zu lesen ist natürlich .....* oder wie Du es geschrieben hast. Stimmen tut aber beides.

[Sidey]

Moin,

Ich denke der Regex stimmt

Ich nicht

Bei Perl bedeutet . ein Zeichen.
Der String muss also mindestens .... Zeichen haben.

Meiner Meinung nach bedeutet dein Regex: Zeile beginnt mit s und anschließend müssen genau 5 Zeichen kommen.
Nicht 6 oder 4.

Perl hat dann die Eigenart, dass es nach dieser Festlegung jedes beliebige Zeichen, sowie auch Länge sein kann.

Bei der Länge stimme ich dir nicht zu. Kannst es ja einfach mal mit ^s.. probieren.

Schöner zu lesen ist natürlich .....* oder wie Du es geschrieben hast. Stimmen tut aber beides.

Bei mir geht es nicht, wenn mehr oder weniger als 5 Zeichen übertragen werden, wenn ich deine Version des regex verwende. Mir ist auch gerade im Moment unklar, wieso überhaupt 5 HEX Zeichen.
Die kommen doch immer paarweise vom Device und danach noch der RSSI Wert, sofern vorhanden. Der belegt ja auch zwei Zeichen.
Bin jetzt aber nicht ganz sicher.

Grüße Sidey

[bjoernh]

Vielleicht liegt ja der unterschied im Perl.

Komisch ist, dass es bei mir und bei anderen Problemlos geht.
Aber ich habe auch kein Problem den Match zu ändern.
Rudolf König hatte mir damals gesagt, dass ich z.B. ....* nicht schreiben brauche, da .... auch genügt.
Vielleicht hat er in fhem was eingebaut.

[rudolfkoenig]

Rudolf König hatte mir damals gesagt, dass ich z.B. ....* nicht schreiben brauche, da .... auch genügt

Match wird nur an eine Stelle geprueft mit

Code Auswählen Erweitern

    next if($dmsg !~ m/$modules{$m}{Match}/i);
s..... bedeutet in diesem Fall s gefolgt von mindestens 5 Zeichen irgendwelcher Art, mehr ist aber auch erlaubt.
s.* bedeutet s gefolgt von irgendetwas oder auch nicht.
Im Endeffekt erlaubt der Patch auch kuerzere Nachrichten.
Ob das sinnvoll ist, muesst ihr bewusst entscheiden.

[Sidey]

Okay,

ich geb mich geschlagen.
Habe es jetzt verstanden, hätte ich so aber nicht erwartet...

Nungut, habe den original Regex noch mal getestet, ich weiss zwar nicht wieso es jetzt geht, aber es läuft.
Vor ein paar Wochen hat es nicht geklappt.

Edit:
Habe meinen Patch angepasst und noch ein paar dinge verändert / korrigiert.

Grüße Sidey

[bjoernh]

Okay,

ich geb mich geschlagen.
Habe es jetzt verstanden, hätte ich so aber nicht erwartet...

Nungut, habe den original Regex noch mal getestet, ich weiss zwar nicht wieso es jetzt geht, aber es läuft.
Vor ein paar Wochen hat es nicht geklappt.

Edit:
Habe meinen Patch angepasst und noch ein paar dinge verändert / korrigiert.

Grüße Sidey

Hallo,

ich habe die Änderungen nun ins SVN übernommen.

Gruß
Björn

[Joker2002]

ist es eigentlich auch möglich, den Sender von Conrad (Eurochron EAS 800z) mit Deiner Software zum Laufen zu bringen ?

http://www.conrad.de/ce/de/product/672687/Ersatz-Zusatzsender-EAS-800-Z-672685-Funk-Wetterstation-EFWS-800-672686-Funk-Wetterstation-EFWS-801?ref=searchDetail

das wäre echt klasse.

[Joker2002]

ich würde mich auch als Tester zur Verfügung stellen

[nicor2k]

Der ist ja wirklich sehr sehr günstig gerade! 
Aber nur noch solange der Vorrat reicht - sonst empfehle ich den TCM Sender, den ich nach Lesen von diesem Thema hier gekauft hab und der mittlerweile (danke BJörn!) super läuft. Kostete bei ebay (neu, inkl. Versand) 6,99 EUR

[nicor2k]

Ich habe ein Problem mit einem der Aldi / GT Sensoren: Am Anfang sendet er immer prima, irgendwann wird er nur noch sporaadisch empfangen. Das ist das Modell GT-WT-01, das als "Prologue" erkannt wird. Eigentlich liegt er direkt neben dem identisch aussehenden, aber doch nicht kompatiblen GT-WT-02 ca. 3-4 Meter vom CUL entfernt - und der GT-WT-02 sendet immer. Batterien bei beiden sind neu.

Hat da jemand eine Idee?