Integration von MySensors in FHEM geplant?

[r_knipp]

Super Job!!!

Danke

- Würde gerne noch die Reihenfolge beim Senden anders herum machen (Klartext nach hinten); wenn der Sendetext zu lang sein sollte, wird hinten abgeschnitten, was bei der Textinfo nicht so tragisch wäre. Einwände?

Nein, das ist ja egal. Wirklich brauchen tut man es ja nicht.

Da wir die ganzen seriellen Infos dann hoffentlich nicht mehr brauchen: #ifdef MY_DEBUG nutzen?

Ja klar, kann raus.

- Protokolle: Wenn ich dazu komme (Tendenz eher am WE), würde ich mal versuchen, PanasonicNew und Samsung32 einzupflegen, oder wird dein BenQ doch bereits erkannt? Die Lib habe ich mal geforked, kann dich gerne auch wieder als Editor zulassen?

Muss ich heute nochmal ausprobieren. Ich glaube das hatte ich noch gar nicht getestet.

- Gibt es erprobte Ideen, was die Reichweite der IR-Diode angeht? Ansonsten würde ich es erst mal mit den weiterführenden Links von Adafruit versuchen (ich habe nur drei "blanke" IR-Dioden, kein Modul).

Hab ich mich bisher noch nicht näher mit beschäftigt. Da der Code jetzt aber läuft ist es als nächstes dran.

Off IR-Topic:
Ach ja: habe noch eine Dunstabzugshaube, die wohl einen 433MHz-Code nutzt (den ich allerdings bisher nicht ernsthaft versucht habe zu decodieren, aber so steht es auf der FB). An sich müßte man die hier entwickelte FHEM<->MySensor-IR-Mimik doch auch nutzen können, um das Teil damit zu steuern, oder? Einen rudimentären Sketch dazu gibt es in der 2.0.0 beta (bislang nur für's Empfangen).

Das Prinzip sollte nach meinem Verständnis das gleiche sein. Halt nur eine andere Übertragungstechnik.

[Beta-User]

Hab ich mich bisher noch nicht näher mit beschäftigt. Da der Code jetzt aber läuft ist es als nächstes dran.

Größere Leistung scheint kein Hexenwerk zu sein, siehe Anhang (aus der IRLib-Doku). Für den Fall, dass du keine Grabbelkiste mit Kleinteilen hast: ein paar NPN und PNP hätte ich über (die IRs brauche ich wohl selber) => PN...

[Beta-User]

So, Reihenfolge beim Senden getauscht, das #MY_DEBUG erledigt und den code nochmal um "Reste" gesäubert.

Nochmal: r_knipp: Super Job, klappt jetzt alles einwandfrei!!!!

Meine PNP-Versuche waren dagegen nicht so der Hit, war aber wohl etwas zu sehr in Eile....

[r_knipp]

Meine PNP-Versuche waren dagegen nicht so der Hit, war aber wohl etwas zu sehr in Eile....

hmm... eine LED ansteuern ist jetzt ja eigentlich kein Geheimnis. Ich werde nur leider erst wieder nächste Woche zu Tests kommen.

Schau mal hier: http://www.mikrocontroller.net/articles/Transistor#Wie_finde_ich_den_richtigen_Transistor_f.C3.BCr_eine_LED-Ansteuerung.3F

Die IR-LEDs kannst du gepulst, was ja hier der Fall ist, übrigens mit bis zu 1A betreiben.

[Edi77]

Hallo,

Ich wollte mal mit mysensors ein LCD 20x4 anbinden, aber ich habe keine Syntax gefunden wie ich z.B. die Werte von meinem KS300 ans Display übermitteln kann.
Vielleicht hat ja jemand das mal gemacht oder einen Link?

[Beta-User]

Hallo,

Ich wollte mal mit mysensors ein LCD 20x4 anbinden, aber ich habe keine Syntax gefunden wie ich z.B. die Werte von meinem KS300 ans Display übermitteln kann.
Vielleicht hat ja jemand das mal gemacht oder einen Link?

Keinen Link, aber eine Vermutung: Es sollte gehen. Das "Problem" ist nur, die anzuzeigenden Inhalte an die Node zu schicken und dort sinnvoll zu verarbeiten. Es sollte aber mit einem (oder mehreren) S_CUSTOM "Kindern" gehen. Damit sollten sich eigentlich jeweils 5 beliebige Inhalte (begrenzter Länge) hin- und herschicken lassen. (Habe aber keine Ahnung, ob die V_VARx irgendwie auf einen bestimmten Datentyp beschränkt sind; bei IR_SEND war Text kein Problem).

Beim Senden mußt du darauf achten, dass die Variable in FHEM bereits gemapped ist. Für unsere IR-Fernbedienung brauchte es z.B. noch

Code Auswählen Erweitern

attr MYSENSOR_xxx mapReading_ir_send3 3 ir_send.

Tendenziell würde ich das ähnlich wie das HM-OLED-Display angehen, also den anzuzeigenden Inhalt auf einen oder mehrere Child-IDs legen und dann die Anweisung, welcher der Inhalte anzuzeigen ist auf eine andere (bzw. ggf. mehrere).
Wie man beim Empfangen nach der Child-ID sortiert, ist gut an den mehrfach-Relay-Beispielen zu sehen.
Inwieweit das den Arduino fordert, würde mich auch interessieren. (Habe für "irgendwann mal" auch ein grafisches SPI-LCD hier liegen, für den Fall, dass mir mal langweilig wird )

[Beta-User]

Vielleicht hat ja jemand ...einen Link?

...doch noch ein Link: https://www.openhardware.io/view/23/In-wall-LCD-SwitchScene-controller-for-MySensors#tabs-source.

Da klappt zumindest die Abfrage der Uhrzeit aus dem Controller und die gleichzeitige Ansteuerung eines (Grafik-) Displays (+Temp + diverse Taster); aktiv was vom Controller versenden lassen, ist das was wir hier vor kurzem mit remotecontrol und IR gemacht haben, also per notify (wenn der KS etwas neues an FHEM gesendet hat. Zeitgesteuert ginge damit auch.

Bleibt die Frage, welche Variablentypen V_VARx sein dürfen, wenn man das mit S_CUSTOM verheiratet...

[r_knipp]

(Habe aber keine Ahnung, ob die V_VARx irgendwie auf einen bestimmten Datentyp beschränkt sind; bei IR_SEND war Text kein Problem).

Also nach meinem Verständnis spielt das keine Rolle. Wenn ich in FHEM ein Sende-Reading setze wird wahrscheinlich eh immer ein String verschickt.
Ich denke die Variablentypen sind nur zur Identifikation der Sensoren. Ein Node kann ja z.B. mehrere (bis zu 254) Sensoren haben.
Auf die entsprechenden Variablen kann man dann ja beliebige Readings mappen.
Im Sketch des Nodes kann ich dann abfragen von welchem Typ die empfangenen Daten sind.

Code Auswählen Erweitern


if (message.type == V_TEXT)

und sie entsprechend unterschiedlich verarbeiten.

Für ein LCD gibt es in der 2.0 beta z.B. den Typen V_Text.

...doch noch ein Link: https://www.openhardware.io/view/23/In-wall-LCD-SwitchScene-controller-for-MySensors#tabs-source.

Hier empfängt er ja auch nur einen String mit dem Temperaturwert und zeigt ihn auf dem Display an.
Ich würde jetzt beim KS300 auch einfach einen String mit Temperatur und Windgeschwindigkeit (oder was das Teil noch kann) schicken und im Node zerlegen.

Worüber ich nichts gefunden habe ist, ob man ein Node z.B. mit S_INFO zu einem LCD Text Device machen kann und ihm statt V_TEXT mehrere V_VARx zuweisen kann, um Temperatur, Windgeschwindigkeit, etc. separat zu verschicken.
Müsste man mal nen Testsketch machen und schauen was FHEM draus macht.

[Beta-User]

Also nach meinem Verständnis spielt das keine Rolle. Wenn ich in FHEM ein Sende-Reading setze wird wahrscheinlich eh immer ein String verschickt.

Hier empfängt er ja auch nur einen String mit dem Temperaturwert und zeigt ihn auf dem Display an.

Müsste man mal nen Testsketch machen und schauen was FHEM draus macht.

Sehe ich ähnlich. Tendenziell geht halt immer eine Folge von Bytes hin und her, wie das zu interpretieren ist, ist jeweils Sache des Controllers bzw. der Node. Dass der zitierte Sketch tatsächlich auch was empfängt, war mir ganz entgangen , ich hatte nur gesehen, dass da ein DS18B20 dran hängt...

Allerdings würde ich das Text-Processing und Formatwandlungen in der Node lieber vermeiden . Das geht zwar und @r_knipp: Klasse Demo, was da möglich ist . Bei einem LCD würde ich aber eher von FHEM aus direkt handhabbare Stücke liefern und dafür die Zahl der Variablen höher wählen (ähnlich wie das Registersetzen der HM-Displays, daher auch S_CUSTOM*n als Vorschlag, da hat man pro Child-ID jeweils die höchste Zahl der möglichen Bausteinchen/Variablen). Das sollte auch besser sein für den Speicherhunger des Sketches, oder?
Die Frage, an welches "S_CUSTOM[n]" sich die Controller-Message richtet, läßt sich bei der Message-Auswertung einfach über "message.sensor" abfragen.
Damit ließen sich auch Umschaltbefehle für das ganze Display codemäßig leichter trennen von "reinen" Inhalts-updates (z.B. S_CUSTOM[1] für Darstellungsanweisungen, S_CUSTOM[2-4] für welche Inhalte auch immer...

Was den Testsensor angeht: Bin sowieso dabei, mein nicht so richtig funktionierendes China-Bewegungsmelder-LED-Leuchtmittel in der Garage mit Hilfe eines Multisensors zu ersetzen. Der soll u.A. auch eine "echte" Bewegungsmelder-Funktionalität bekommen und dabei vom Controller aus konfigurierbar sein, was Einschaltdauer und Umgebungslicht angeht.

Erste Fragmente des Bewegungsmelders+ liegen auf Github, wenn's jemanden interessiert (Achtung: kein Display geplant und v.a. wg. des BMP180 recht unübersichtlich; da geht es zunächst mal "nur" um die Konfigurierbarkeit): https://github.com/rejoe2/MySensors-Garage.

[r_knipp]

Was den Testsensor angeht: Bin sowieso dabei, mein nicht so richtig funktionierendes China-Bewegungsmelder-LED-Leuchtmittel in der Garage mit Hilfe eines Multisensors zu ersetzen. Der soll u.A. auch eine "echte" Bewegungsmelder-Funktionalität bekommen und dabei vom Controller aus konfigurierbar sein, was Einschaltdauer und Umgebungslicht angeht.

Wenn du Lust hast könntest du dann ja auch mal ausprobieren, ob man sich nicht auch selber einen neuen Sensor definieren kann.
Ich würde fast wetten, dass man dafür nur die entsprechenden S_ und V_ sub-types in der MySensors.h definieren muss.

[Beta-User]

Wenn du Lust hast könntest du dann ja auch mal ausprobieren, ob man sich nicht auch selber einen neuen Sensor definieren kann.
Ich würde fast wetten, dass man dafür nur die entsprechenden S_ und V_ sub-types in der MySensors.h definieren muss.

Es sollte tendenziell tatsächlich kein großes Problem sein, die Anzahl der Typen zu erhöhen (Definitionen stehen wohl in der /core/MyMessage.h). Allerdings könnte die Definition neuer Sensor-Typen im Sinne einer typischen Zusammenstellung von Informationen noch einfacher sein:
Wenn ich mich recht entsinne, hatte ich in der Vergangenheit hin und wieder beim Zusammenstricken der Sketche für Multi-Sensoren den "Fehler" gemacht, die Child-IDs diverser Hardware nicht sauber auseinanderzuhalten. MySensors meckerte da nicht rum. Was möglicherweise nicht funktioniert hat, ist das autocreate von FHEM (hab das alles natürlich wieder gelöscht, ist nicht mehr nachvollziehbar)....
Das ließe sich sicher durch das Aufbohren von MYSENSOR_DEVICE.pl oder manuelle Zuordnungen beheben; bleibt die Frage, ob das überhaupt Sinn macht , wenn es mit "Bordmitteln" bereits ganz ordentlich funktionieren sollte (was sich nach meiner Erfahrung grundsätzlich besser mit updates verträgt).

Wo siehst Du den Vorteil eines "neuen" Sensortyps?

[r_knipp]

Das ließe sich sicher durch das Aufbohren von MYSENSOR_DEVICE.pl oder manuelle Zuordnungen beheben;

Ich glaube das ist gar nicht nötig. Wenn man die S_ und V_ sub-types richtig definiert.
Das Modul zieht sich sicher aus der presence message die sub-types und legt entsprechend auch die Readings an.
Dem ist bestimmt auch egal wie die genau heißen.

Wo siehst Du den Vorteil eines "neuen" Sensortyps?

Eigentlich wärs nur ganz interessant obs funktioniert
Ansonsten könnte man sich so ja nen eigenen Sensor bauen wenn die verfügbaren nicht passen. Vor allem bei Multisensoren.

[Beta-User]

Ich glaube das ist gar nicht nötig. Wenn man die S_ und V_ sub-types richtig definiert.
Das Modul zieht sich sicher aus der presence message die sub-types und legt entsprechend auch die Readings an.
Dem ist bestimmt auch egal wie die genau heißen.

Also nach unseren Erfahrungen mit der IR_SEND-Geschichte würde ich steif und fest behaupten, dass FHEM per autocreate nur anlegt, was in MYSENSORS_DEVICE.pm (sorry für den typo) sauber angelegt ist (bzw. nachträglich per "attr mapreading..." eingepflegt wird).
Und beide MS-perl-Module scheinen keine Übersetzung von Ziffern (Sendeprotokoll) nach Variablen (Klartextnamen) zu machen, das spuckt demnach das Gateway bereits rückübersetzt aus; das würde dann auch an der Stelle nach exakter Schreibweise bzw. Einhaltung der vorgegebenen Namen verlangen.

Eigentlich wärs nur ganz interessant obs funktioniert

Genau darum ging's mir mit meinem konfigurierbaren Bewegungsmelder; ob man dazu jetzt noch eine Child-ID mehr oder weniger verbrät, ist m.E. nicht so wichtig . Wenn es aber geht, sollte es praktisch auf alle Anwendungsfälle übertragbar sein, also z.B.
- das Info-LCD
- Bewegungsmelder+Relay/LED ohne eigenen Lichtsensor (Info dann über den Controller; da fällt mir doch gleich auch noch eine Stelle ein, wo das ohne großen Aufwand hilfreich wäre !!!)
- ....

Wenn ich das alles nur vorher halbwegs verstanden hätte ! Dann
- hätte ich nicht so oft in den Keller rennen müssen zum Nano-Wechseln
- wäre manches DOIF gespart worden und diese Logikteile direkt im Arduino untergebracht
- hätte es am Wochenende bestimmt draußen 10 Grad mehr gehabt

[r_knipp]

Also nach unseren Erfahrungen mit der IR_SEND-Geschichte würde ich steif und fest behaupten, dass FHEM per autocreate nur anlegt, was in MYSENSORS_DEVICE.pm (sorry für den typo) sauber angelegt ist (bzw. nachträglich per "attr mapreading..." eingepflegt wird).

Ach ja, das gibt's ja auch noch. Sorry, hatte die ganze Zeit nur das Gateway Modul im Kopf und in dem hatte ich nichts sensorspezifisches gefunden.

Gerade mal reingeschaut. Du hast Recht. Das Device Modul müsste man erweitern.
Also vielleicht doch am besten custom. Eigentlich ist der Typ ja auch egal. Identifizieren kann man ihn ja über seinen Namen.

Ich frage mich allerdings noch wie das mit mehr als fünf Sensoren funktionieren soll. 
Ein Node kann ja wohl 254 Sensoren. Kann man sich ja mal mit beschäftigen wenn mans denn braucht

[Beta-User]

Hallo,

Ich wollte mal mit mysensors ein LCD 20x4 anbinden, aber ich habe keine Syntax gefunden wie ich z.B. die Werte von meinem KS300 ans Display übermitteln kann.
Vielleicht hat ja jemand das mal gemacht oder einen Link?

Da hat jemand das Display-Problem schon gelöst; zu allem Überfluß auch noch mit FHEM als controller!!!!
https://forum.mysensors.org/topic/1817/weather-and-forecast-display-for-swedish-fhem-users/2

Und dann noch intensive Nutzung von PROGMEM und F zur Speicherung der Variablen! Sehr interessant
Unter der Child-ID 4 (S_SWITCH) findet sich dann auch noch mehrere V_VARn; die einfach gemapped sind; wäre interessant zu wissen, ob das FHEM-device-Modul angepaßt wurde oder ob das "einfach so" geht.

Ich frage mich allerdings noch wie das mit mehr als fünf Sensoren funktionieren soll. 

Also die pure Zahl der Sensoren ist nach meiner Erfahrung kein Problem an sich; ich habe derzeit 2 Nodes, die 5 und mehr Kinder haben; da kommen geplant min. noch 2 dazu. Da wird dann eher die Größe des Speichers zum Thema (daher auch gerne #ifdef MY_DEBUG).