Support für vair-Sensoren?

[vbs]

Hi Ihr,

wäre es wohl irgendwie möglich, Support für die CO²-Sensoren aus diesem Thread zu integrieren?
https://forum.fhem.de/index.php/topic,66592.0.html

Das sind die Sensoren von hier:
http://vair-monitor.com

Ich habe einen solchen Sensor hier und ich kann auch die Nachrichten als Hex per 433 MHz in dem TRX_ELSE-Modul empfangen, also prinzipiell scheint da etwas zu funktionieren. So wie ich das verstehe, werden die Sensoren bereits von der Firmware des RFXTRX unterstützt.

Ich kann leider nicht sagen, nach welchem Protokoll das ganze funktionieren (hab ich auch wenig Ahnung von). Aber ich hab hier einen Thread zum Thema im Support-Forum gefunden:
http://forum.vair-monitor.com/showthread.php?tid=2&highlight=433

Da wurde auch gesagt:

Code Auswählen Erweitern

Good idea to use the RFXSensor protocol for temp, hum and baro because it does not need any adaptation in the applications and RFXtrx.
Heißt das evtl. dass da ein bekanntest Protokoll ("RFXSensor protocol"?) benutzt wird, so dass man das evtl. schon so in FHEM nutzen kann?

Würde auch gerne aushelfen, wo ich kann! Danke!

[Markus M.]

Da wurde auch gesagt:

Code Auswählen Erweitern

Good idea to use the RFXSensor protocol for temp, hum and baro because it does not need any adaptation in the applications and RFXtrx.
Heißt das evtl. dass da ein bekanntest Protokoll ("RFXSensor protocol"?) benutzt wird, so dass man das evtl. schon so in FHEM nutzen kann?

Probier mal Seite 11/12 hier:
https://storage.googleapis.com/google-code-attachments/arduinoha/issue-2/comment-0/wmr928-weijenberg.pdf

[vbs]

Danke dir, muss man scheinbar etwas tiefer einsteigen. Im Moment macht der Sensor bei mir leider ziemliche Probleme, da er offenbar das 433 MHz Band dauerhaft stört, wenn er läuft. Daher erstmal das beheben

[vbs]

So, ich hab mal eine erste Version. Bitte nicht verkloppt, wenn irgendwas noch falsch ist. Ich konnte auch nicht die Bedeutung aller Bytes rausfinden. Das Protokoll nennt sich RFXMeter und hat nach meinem Verständnis mit dem Oregon nichts zu tun.

Der Sensor sendet eigentlich 6-byte lange Nachrichten wie hier von Vladimir beschrieben:
http://forum.vair-monitor.com/showthread.php?tid=2&pid=551#pid551

Aus dem TRX kommen dann 10-byte lange Nachrichten raus. Die sehen so aus:

Code Auswählen Erweitern

0a 7100 10 8676 00 016508 79
0a 7100 19 8676 00 016760 79
0a 7100 29 8676 00 016cd8 69

Ich vermute mal, dass der RfxTrx die Nachrichten irgendwie "vorparst" und zum Beispiel vorne eine Protokoll-ID davor klebt. Ich konnte verdammt nochmal 0 Infos dazu finden, in welchem Format dieser RfxTrx seine Nachrichten ausgibt 

Folgende sind noch unklar:
0a     7100 19  8676 00 016760 79
Len   ID      ??  Adr   ??  value     ??

Zum Beispiel finde ich nicht die 4-Paritäts-Bits in der Nachricht. Evtl. wird der Parity-Check auch schon im RfxTrx vorgenommen.

Also mein aktueller Stand im Anhang. Falls da noch jemand Bedarf für hat, dann gerne mal testen. Falls jemand noch Ideen zu dem Protokoll hat, dann auch gerne raus damit.

Zur Nutzung des Moduls:
Die Devices sollten ganz regulär per autocreate angelegt werden. Danach kann man noch bei Bedarf die Definition anpassen und den Namen des Readings anpassen, zB:

Code Auswählen Erweitern

RFXMETER_118 0.01 CO2

Das "0.01" ist der Skalierungsfaktor für die Werte. der vAir sendet mit Faktor 100. Also hier dann 0.01 eintragen.

[KölnSolar]

Ich vermute mal, dass der RfxTrx die Nachrichten irgendwie "vorparst" und zum Beispiel vorne eine Protokoll-ID davor klebt.

genau so ist es. Wir haben keine chance "echte" raw Daten zu empfangen. Sprich:
1. die richtige/passende firmware muss installiert sein
2. das richtige/passende protocol muss aktiviert sein(wobei die Aktivierung mancher protocol sich gegenseitig beeinflussen bzw. zu einer schlechteren Erkennungsrate führen.)
3. Modul TRX empfängt die Daten raw(aber nicht wirklich raw, sondern raw des RFXTRX)
4. die Bytes 3-6 beinhalten das erkannte device-Protokoll, wobei über die Byte 3-4 die Zuordnung zu den diversen "Parse"-Modulen TRX_xyz erfolgt und Kennzeichen für das "Haupt-Protokoll" ist.
5. im konkreten Modul TRX_xyz erfolgt dann die eigentliche Auswertung. Hier erfolgt dann anhand der Bytes 3-6 die Zuordnung zu, ich nenn es mal, Protokollvarianten.

Bytes 7-8 sind einfach nur eine laufende Nr. des RFXTRX.

Somit ist dann klar, dass für "7100" in das Modul TRX_ELSE verzweigt wird, wo es dann aber keine passende Parsing-Routinen gibt ;-(

Ich vermute, dass das letzte Byte den RSSI wiedergibt. Schalte mal das Attribut rssi im TRX auf 1, dann kannst Du das evtl. verifizieren.

Grüße Markus

[vbs]

Genau, das hab ich jetzt so implementiert. Falls das mal jemand reviewen mag, dann wäre das super.

3. Modul TRX empfängt die Daten raw(aber nicht wirklich raw, sondern raw des RFXTRX)

Hast du irgendwo schonmal eine konkrete Spezifikation dazu gefunden? Ist mir schleierhaft, dass die für mich nicht aufzufinden ist. Ohne die Specs ist so ein RFXTRX ja nur von begrenztem Nutzen. Aber in den ganzen Dokus von rfxtrx.com hab ich nix finden können

4. die Bytes 3-6 beinhalten das erkannte device-Protokoll, wobei über die Byte 3-4 die Zuordnung zu den diversen "Parse"-Modulen TRX_xyz erfolgt und Kennzeichen für das "Haupt-Protokoll" ist.

Das passiert über das zweite Byte, sprich die "71" in obigen Fall.

5. im konkreten Modul TRX_xyz erfolgt dann die eigentliche Auswertung. Hier erfolgt dann anhand der Bytes 3-6 die Zuordnung zu, ich nenn es mal, Protokollvarianten.

Bytes 7-8 sind einfach nur eine laufende Nr. des RFXTRX.

Kannst du das mal an einer konkreten Nachricht benennen? Zählst du 0- oder 1-basiert? Zählst du das erste Längenbyte mit? Meinst du mit laufender Nummer eine Art Seriennummer des RFXTRX oder eine bei jeder Nachricht hochzählende ID? Das Format ist mMn wie oben schon beschrieben. Nur die ?? sind mir noch unklar.

[KölnSolar]

Hast du irgendwo schonmal eine konkrete Spezifikation dazu gefunden?

Nein, da macht Bert ein ziemliches Geheimnis draus. Zu Recht, wie ich finde. Steckt ja immer viel Arbeit drin ein neues Protokoll zu implementieren.

Das passiert über das zweite Byte

Klar, ich Depp. Ersetze in meinem Post Byte durch Nibble 

Meinst du mit laufender Nummer eine Art Seriennummer des RFXTRX oder eine bei jeder Nachricht hochzählende ID?

Letzteres, aber eben nicht Byte, sondern Nibble 7-8

Nur die ?? sind mir noch unklar.

lfd. Nr; ich vermute die longid, sofern vorhanden und genutzt; RSSI

[vbs]

Ahh ok, dann sind wir da glaub ich auf der gleichen Schiene. RSSI klingt plausibel, werde ich mir nochmal ansehen.

Code Auswählen Erweitern

Nein, da macht Bert ein ziemliches Geheimnis draus. Zu Recht, wie ich finde. Steckt ja immer viel Arbeit drin ein neues Protokoll zu implementieren.
Meinen wir hier dasselbe? Ich kenne Bert nicht, aber ich vermute mal, dass der Entwickler hinter RFX ist.
Aber ich meine: ich kaufe für 100€ einen RfxTrx433 und nun muss ich doch um das Gerät nutzen zu können, eine Spezifikation darüber bekommen was die Bytes bedeuten, die aus der seriellen Leitung purzeln. Oder was ist der normalen Anwendungsfall für so einen Käufer?
Dieses Tool RfxMg für Windows ist doch nur ein Debug-Tool um zu überprüfen, was das Ding prinzipiell sieht, oder?

[KölnSolar]

Meinen wir hier dasselbe? Ich kenne Bert nicht, aber ich vermute mal, dass der Entwickler hinter RFX ist.

Jo, meinen wir. Und man kann da unterschiedlicher Ansicht sein. Bedenke einfach, dass der RFXTRX kein Open-Source-Projekt ist. Ist halt eine andere Philosophie, als der CUL(war auch mal anders) oder Signalduino.
Und wenn Vladimir dann in Abstimmung mit Bert ein vorhandenes Protokoll "missbraucht" ......sollte er auch Sorge dafür tragen, wie das in FHEM mit dem RFXTRX umgesetzt wird.
Früher hat Willy für die Implementierung neuer Protokolle/Geräte in FHEM in Abstimmung mit Bert gesorgt. Nur Willy ist ja seit langem abgetaucht  Und das ist unser eigentliches Problem: Unserer FHEM-Community fehlt die Schnittstelle Willy  Neben neuen Protokollen wäre auch einiges an den Modulen zu tun....
Und nicht, dass der falsche Eindruck entsteht: Trotzdem es kein Open-Source-Projekt ist, ist die Bereitschaft FHEM seitens RFXCOM zu unterstützen auf jeden Fall vorhanden.
@Bert: falls Du mitliest, stelle gerne Dinge klar, die ich evtl. missverständlich ausgedrückt habe. Gerne auch per PN.

Und um es noch in einem etwas anderen Licht erscheinen zu lassen: Mit dem RFXTRX kriegen wir das schon irgendwie als community hin. Ich vermute mal, dass FHEM nicht der Fokus von Vladmir ist. Denn eine Implementierung für CUL, Signalduino........

[vbs]

Sorry, bin gerade echt baff... ich dachte, ich hätte einfach schlecht gegoogelt oder den normalen Use-Case nicht verstanden. Ich kann doch kein Gerät verkaufen, das ein proprietäres Protokoll spricht, aber dann dem Kunden den Aufbau nicht verraten? Wenn ich einen bösen Vergleich anstellen wollte, dann wäre das ja so als ob VW Autos verkauft, aber die Wagenschlüssel einbehält.

Hast du irgendwo schonmal eine konkrete Spezifikation dazu gefunden?

Nein, da macht Bert ein ziemliches Geheimnis draus. Zu Recht, wie ich finde. Steckt ja immer viel Arbeit drin ein neues Protokoll zu implementieren.

Ja, aber aber aber .. die Benutzer zahlen doch immerhin auch einen angemessenen Betrag für das Gerät, oder? Ist ja keine unbezahlte Arbeit (im Gegensatz zur Arbeit, die in OSS steckt wie z.B. FHEM).

[KölnSolar]

Ich finde, Du verdrehst jetzt etwas die Tatsachen. Ausgangspunkt ist der proprietäre SmartHome-Markt. Fast jeder Hersteller kocht sein eigenes Süppchen, sprich Protoköllchen. Kaum jemand lässt sich dabei in die Karten gucken, weil es Firmengeheimnisse sind, die die Existenz sichern sollen. Mal mehr, mal weniger erfolgreich. Umgekehrt ist es aber genau das Problem, warum sich das Thema SmartHome nicht schneller entwickelt. Gerät A funktioniert eben nicht mit Transceiver von Hersteller B. Aus dieser Situation heraus sind viele Projekte entstanden, die genau das verändern wollen. FHEM ist eins davon. Aber auch der RFXTRX. Kaufe ich mir nun den RFXTRX, so tue ich dieses erst einmal, weil das Gerät in FHEM nutzbar ist und gefühlte 100 Protokolle und 1.000 Gerätetypen unterstützt. Und ganz ehrlich, sind da eigentlich nicht 100 EUR wenig Geld ? Kann ich dafür erwarten, dass zukünftige Protokolle/Geräte nutzbar sind ?

Um bei Deinem PKW-Beispiel zu bleiben. Veröffentlicht VW die Kodierung seiner Funk-Schlüssel, damit Du Dir einfach einen Schlüssel "nachmachen" kannst oder musst Du dann nicht für viel Geld einen eigentlich "dummen" Schlüssel  bei VW kaufen ? Sind bei einem VW Updates der Navigationssoftware kostenlos ? Kannst Du Updates selber machen ? Das ließe sich endlos fortsetzen.

Und wie ich schon schrieb: Vladimir als Hersteller des Sensors, um mal wieder zum Thema zurückzukommen, müsste mal seine Strategie darlegen und sollte die ein Absatzinteresse im FHEM-Markt beinhalten, auch kümmern wie das device erfolgreich eingebunden wird. Ich habe da den Eindruck, dass er primär für Domotica(enger mit RFXCOM verbandelt als FHEM) entwickelt hat und jetzt auch FHEM-User ihr Interesse an dem Sensor entdeckt haben. Vielleicht hat er aber auch primär auf WLAN gesetzt ? In seinem Forum findet sich ja herzlich wenig zu RF.

Und Du stellst es auch ein wenig dar wie "100 EUR gezahlt und es gibt keinen Support." Dem muss ich vehement widersprechen. Man ist bei RFXCOM sogar sehr hilfsbereit und die Konstruktionspläne von VW werden doch auch nicht veröffentlicht.

Aber alles meine persönliche Sicht. Konkrete Strategien und Geschäftsinteressen kennen ich weder von Vladimir, noch von RFXCOM, um das Ganze fundierter beurteilen zu können.

Jetzt aber mal wirklich zurück zum Thema: Hab ich es richtig verstanden, dass Vladimir eine Software zur Verfügung stellt, wo man eine ID gegen eine Charakteristik, z.B. Temperatur, mapped. Diese ID wird dann übertragen und muss dann wieder als Charakteristik in FHEM entschlüsselt werden, damit man die Daten auch interpretieren kann ? Sprich FHEM weiß erst einmal nicht, ob ein Datensatz einen z.B. temperaturwert übermittelt ? Wenn ja, dann würde das ja nicht zur bisherigen Philosophie der 1:1 Übersetzungen in den TRX_XYZ-Modulen passen. Im Gegensatz zu Deinem 1. Wurf, die Logik des RFXMETER-Moduls in das TRX_WEATHER zu kopieren, fände ich es logischer(aus TRX-Modulsicht), eine Logik in das TRX-Modul zu packen und dann das RFXMETER-Modul oder ein neues "Vladimir-Multi-Sensor-Modul" anzusteuern. Oder aber die Daten so aufzubereiten, dass Sie durch Folgemodule wie TRX_WEATHER mit kaum verändertem Grundaufbau zu verarbeiten sind. Letzteres hätte den Nachteil, dass man zu der Vielzahl der Charakteristiken mehrere devices in FHEM bekäme.

[vlast3k]

Hallo, ich habe erst jetzt gesehen dass ihr hier über die vair Sensoren diskutiert. Ich bin der Hersteller - Vladimir.
Da ich schon viele anfragen bekommen habe - wie man über RFXCom kommuniziert, habe ich mit Bert in Verbindung getreten um unterstuetzung für meine Devices in den RFXCom firmware zu haben. Ich hoffe das es bald arbeiten wird.