are there more supported protocols planned?

[Dattel]

Hi, i'm wondering, if there are attempts to support more different transmitters in future releases? Currently i'm using a signalesp with the homeautomation system FHEM to collect some RF data from the "EAS800z, FreeTec NC-7344, HAMA TS34A, Auriol AFW 2 A1"-compatible protocol, but i'm also very pleased with Openmqttgateway, which supports the WeatherStationDataRX Lib since a few builds.

How are the chances, that i could replace my signal-esp in future? Thanks for your work :-D

[Zwer2k]

Unfortunately rather small, because I do not have such devices to test the function. Openmqttgateway already supports many devices. Maybe something will come along.

[Dattel]

So i must came back to these topic.. I played around a bit with your code since i have 2 different sensors i would like to readout with your libary and OpenMqttGateway. Both sensors seems not to be native supported.

I analyzed the signals a bit and managed to decode them... But my approach was a bit different to yours... but i think i wouldn't publish my current implementations because of the lack of clean c code knowledge :-D and i think there is no need of another mqtt module for SensorReadings if we can combine them to one. So I hope, i can inspire you a bit - i would be ready to contribute my both sensor implementations

Here is a short overview, what i do different:

1. in the RF433-Callback function i try to receive a full signal (normally about 36 bits seems to be the full signal) and than storing these complete signal into a ringbuffer without analyzing it at these point. (including the HI/LO&Average timings because i read that these timing informations can be important to help determining the correct sensor type later)

2. in a workerfunction from the loop i poped the signals from the ringbuffer and passed it into a "analyze" function to determine the correct type of the struction.

3. if a type can be determined, i read out the real values from the signal.

If you are interessted, please let me know - i would be glat :-)

[Dattel]

vielleicht können wir auch einfach auf Deutsch schreiben - ist vielleicht einfacher :-D Irgendwie fällt mir jetzt erst auf, das der Code deutsche Kommentare enthält

[Zwer2k]

Hallo Dattel, wir können gern auf Deutsch schreiben. :-) Eigentlich ist das Vorgehen von dir nicht viel anderes. Beim Empfangen wird nur geschaut ob die Datenpakete in Frage kommen, anderenfalls währe zu großer Ringbuffer erforderlich, vor allem wenn viele Sender in der Gegend sind. Die eigentliche Überprüfung inkl. Checksumme erfolgt erst wenn die Daten abgerufen werden. Wenn du dein Code Bereitstellen könntest, kann ich schauen ob ich es integrieren kann. Am besten ein Git-Fork mit deinem Stand anlegen.

Gruß

[Dattel]

Okay, dann kannst du dir ja mal das folgende Repository anschauen. Implementierung funktioniert mit 3 "unterschiedlichen" Sensoren. Bei der Namensgebung habe ich mich an die SignalDuino Implementierung gehalten :-D

1x TCM97001 (Diese haben offensichtlich extrem lange Bits) 2x SD_WS07 Sensoren (unterschiedliche Hersteller)

Bitte nicht gleich die Hände über dem Kopf zusammenschlagen - da ist nicht mehr viel von deiner Implementierung übrig geblieben. Sogar der Name ist anders :-D... Das liegt aber da dran, da ich meine Implementierung ebenfalls zum Testen im OpenMqttGateway eingebunden hatte und Konflikte vermeiden wollte.

Deine rx433Handler Funktion habe ich komplett umgekrempelt nach diesem Vorbild . Grund: Mein RBX8 Sensor hat mit deiner Implementierung nur Müll produziert und im Grunde permanent nur neue Geräte pairen wollen, die es nicht gibt.

Auch fehlen gänzlich deine Flag's, welche Änderungen angekommen sind - das ist aber bei meinen einfachen Sensoren irrelevant, da die nur einen Typ von Signal mit "Vollständigen" Daten liefern... Solltest du trotzdem noch Interesse haben, dann sollte das logischerweise mit eingebaut werden. Dein Sensor fehlt auch komplett, da ich halt nur andere Typen habe - sollte aber 1:1 einbaubar sein.

Ich speichere zusätzlich noch die High/Low Zeiten -> eventuell wird das mal hilfreich, wenn Sensoren ähnliche Dialekte sprechen und nur noch über die Zeiten zu unterscheiden sind.

Was ich z.B überhaupt nicht durchblickt habe ist das Konstrukt mit den 4 __instances im CTor und DTor. Lief bei mir ohne, deshalb habe ich das rausgenommen.

Würde mich auf jeden Fall über Feedback freuen....

[Zwer2k]

Der Link auf die Repo scheint nicht zu passen. Kannst du bitte noch einmal prüfen.

[Dattel]

jetzt? Hatte das Rep auf private.

[Dattel]

Hast du dir das mal angeschaut?

[Zwer2k]

Hallo @Dattel , sorry, dass ich so lange nicht geantwortet habe. Dein Code habe ich gleich damals angeschaut. Es sieht sehr gut aus, ich finde auch, dass es sauber implementiert ist. Ich hätte auch nichts dagegen, wenn dein Code als Basis genommen wird, da du bereits eine Art Plugin-System implementiert hast. Leider komme ich zurzeit nicht dazu den Umbau in angriff zu nehmen. Wenn du Zeit und Lust hast, kann ich dich gerne auf die Repository berechtigen.

Das mit __instance wird verwendet um mehrere Instanzen mit mehreren Empfängern zu ermöglichen. Hab ich damals auch irgend wo abgeschaut :-)

Viele Grüße

[Dattel]

hmmm... Ich hab mir das ganze jetzt auch schon eine Weile nicht mehr angeschaut - denke aber, dass meine "Plugin"-Implementierung noch nicht wirklich der Königsweg ist... Ist ja auch etwas mit der heißen Nadel gestrickt.

Zwischenzeitlich habe ich mit mal https://github.com/couin3/RFLink angeschaut - die arbeiten auch mit einer Art Plugin-System - allerdings habe ich da schnell erkannt, dass es ganz schnell ganz kompliziert werden kann, je mehr unterschiedliche Sensoren und Dialekte dazu kommen. Meine Sensoren sind damit im Übrigen auch nicht alle abgebildet worden, weshalb ich das schnell beiseite gelegt habe.

Also, als Contributor bin ich gerne bereit, meine Sensoren dazu zusteuern und ggf. kleine Änderungsumsetzungen zu machen, aber meine Skills reichen gerade in C nicht aus, um speichereffektiv genug zu arbeiten, dass man das hier SO-WIE-ES-JETZT-IST veröffentlichen kann. Gerade die Pointerei ist nicht mein Steckenpferd