Integration von MySensors in FHEM geplant?

[ntruchsess]

das Modul 'MYSENSORS_SENSOR' hat jetzt ein Attribut 'setCommands' mit dem man dynamisch Werte für 'set' definieren kann:

Code Auswählen Erweitern


attr MY_LIGHT_47_11 setCommands on:V_LIGHT:0 off:V_LIGHT:1


damit kann man 'set MY_LIGHT_47_11 on' und 'set MY_LIGHT_47_11 off' aufrufen.

alternativ:

Code Auswählen Erweitern


attr MY_LIGHT_47_11_set_V_LIGHT 0 1


erlaubt: 'set MY_LIGHT_47_11 V_LIGHT 0' bzw. 'set MY_LIGHT_47_11 V_LIGHT 1'

- Norbert

[ntruchsess]

Hallo Alexander,

ich habe grade noch Default-attributewerte für per autocreate angelegte Devices eingeführt.

Ich würde aber gerne da mitarbeiten. Wo könnte ich Dich unterstützen?

Eine große Hilfe wäre für die einzelnen Sensor-typen sinnvolle defaults zu ermitteln und da einzupflegen...

Hast Du eine Ahnung, welche Semantik beim Acknowledge-flag erwartet wird (das ignoriere ich bisher völlig)?
Und bei den Internal-messages gibt es auch noch einige weiße Flecken auf der Landkarte, bei denen ich nichts dokumentiertes drüber finde...

Was hat es eigentlich mit dem 'inclusion-mode' des Gateways auf sich? Ich hab das per 'set inclusion-mode on/off' schaltbar gemacht, aber was bewirkt das eigentlich? Ich hab im Verhalten des Gateways keinen Unterschied feststellen können...

soll ich das Gateway-reading 'log-message' für die Log-messages eigentlich drin lassen, oder reicht es da einfach mit Loglevel 4 ins Log zu schreiben?

Und zu guter letzt: soll ich die Module noch mal umbenennen? z.B. MYS_GW für das Gateway, MYS_NODE und MYS_DEVICE für die beiden anderen? Habt Ihr bessere Vorschläge?

Gruß,

Norbert

[hexenmeister]

Hi Norbert,

Du warst ja schon richtig fleißig

Ich habe jetzt etwas Zeit, will mir das alles ansehen. Mit den Default werde ich mir Gedanken mache, bei der Gelegenheit würde ich gerne noch den Readings 'richtige' namen geben. Am besten auch in Form von Default, Idealerweise per Attribut überschreibbar. Was hälst Du davon, gleich auch Maßeinheiten mit aufzunehmen? Ich würde sogar immer nur metrisches System lassen, oder kann jemand Imperial brauchen?

Ack habe ich mir noch nicht wirklich angesehen. Ich denke, man kann das frei handhaben, wird es angefordert, wird es beantwortet. Für Aktoren, denke ich, wäre Ack angebracht. Sensoren wollen auch ein haben. Scheint so, dass bis auch einige Service-Befehle ACK überall gewünscht wird.

Include war für mich auch ein Rätsel. Im Sketch habe ich (zugegeben auf die Schnelle) auch nichts sinnvollen gefunden. Ich denke, das ist ein Signal an Controller (also in unserem Fall FHEM), neue Sensoren zuzulassen. Man kann ja am Gateway per taster starten. Mach auch Sinn, da ansonsten bekommt ein 'jungfreulicher' Sensor beim ersten Test gleich eine ID, die man nicht ohne weiteres wieder ändern kann.

Bei Log-Messages habe ich gestern auch zunächst gedacht, dass da was sinnvolles zu loggen wäre. Dafür ist der Gateway aber zu gesprächig mit seinen Logs. Steht auch unwichtiges Zeug drinn. Ich  würde die auf Level 5 loggen.

Ob man die Module umbenennen soll, bin ich mir auch nicht sicher, ich hatte gerstern meine MS_LINK und MS_DEV genannt. MYS klingt auch iwi nicht sonderlich gut. Ich würde so lassen, MYSENSORS, MYSENSORS_NODE und MYSENSORS_DEVICE klingen doch ganz gut.

Grüße,

Alexander

[hexenmeister]

So, installiert und läuft erstmal.

Mein Perl ist pingeliger als deiner. Ich musste in 00_MYSENSORS Zeile 241 um 3. Parameter erweitern: DevIo_SimpleWrite($hash,"$txt\n", undef);

Nach dem ich autocreate eingeschaltet habe (dies könnte man durch den Inclusion-Taster automatisch tun) wurden zu meinem Humidity-Sensor 3 Devices erstellt:
MY_ARDUINO_NODE_1_255
MY_HUM_1_0
MY_TEMP_1_1

Nach meinem Geschmack etwas zu viel. Vor allem Arduino-Node ist eigentlich zu nichts zu gebrauchen. Sogar darin enthaltenes Attribut "coonfig" scheint nicht zu funktionieren. Dort steht zwar M, Temp.Sensor liefert jdoch 75. Wird Fahrenheit sein.

[ntruchsess]

Ich bin da offen für Vorschläge, wo man die Funktionalität des Arduino_node (batterylevel, config, ggf. time) sinnvoll unterbringt. Das mit dem 'config'-attribut ist natürlich etwas dämlich, liegt dann aber wohl am Sketch. Wenn Du verbose auf 5 setzt, kannst Du sehen, ob die entsprechende I_CONFIG-message raus geht.

Ich hab noch mal nach dem Inclusion-mode geschaut. Der scheint im MyGateway.cpp wirklich nix anderes zu machen als den Blink-modus zu verändern, damit könnte man den Autocreate-modus anzeigen. Dumm nur, dass der Sketch das selbsttätig wieder zurücksetzt.

- Norbert

[hexenmeister]

Lustigerweise hatte ich gestern mit meinen Modulen korrekte Temperatur anzeige. Dabei hatte ich die Config Message für Metric gar nicht implementiert. Ich muss mal in den Sketch gucken.

Ich finde es gar nicht so schlecht, dass IncludeModus automatisch zurückgesetzt wird. Es dürfte so gemeint sein: Man drückt auf di Taste und hat x-Minuten Zeit einen neuen Sensor anzumachen. Dieser wird registriert und Include-Modus beendet. Da dabei entsprechende Messagen an Controller rausgehen, können wir sauber darauf reagieren. Und autocreate-Attribut kann z.B. parallel dazu genutzt werden, diesen Modul daurhaft einzuschalten.

Was spricht dagegen, alle Readings und Steuerungen eines Hardware-Devices, wie bei meisten anderen Systemen auch nur in einer SoftwareModul-Instanz zusammenzufassen? Ich stelle mir nur eine Flut von FHEM-Devices, wenn ich in jedem Zimmer so ein Temp/Hum/Light-Sensor installiere

[ntruchsess]

wg. inclusion-mode: habe ich gerade mit 'autocreate'-attribut funktionell zusammengelegt (und ins git committed). Bei aktiviertem 'inclusion-mode' werden Devices automatisch angelegt, wenn Presentation-messages eintreffen. Ist autocreate gesetzt, wird 'inclusion-mode' im Gateway aktiv gehalten. Ist 'autocreate' nicht gesetzt, kann man den 'inclusion-mode' vom Gateway aus oder per set-commando aktivieren (setzt sich bei nicht gesetztem 'autocreate' nach 1 Minute von selber wieder zurück).

Wg. Zusammenlegen 'Node' und 'Device': dagegen spricht, dass man dann in einem Device viele, ggf. equivalente Readings hat. Also wenn man z.B. einen Sketch für eine Relays-karte macht kann man die Relays nicht mehr (ohne Readingsproxy) einfach auf der Weboberfläche ein-/aus-schalten. Die Readingproxies könnte man aber natürlich optional automatisch mit dazu anlegen (damit könnte ich mich auch anfreunden...)

Gruß,

Norbert

[hexenmeister]

Mit Inclusion klingt sauber.

Den Einwand wg. Einzeldevices verstehe ich. Beide Wege bringen Nachteile mit sich. Ich denke noch  darüber nach. Ein Argument wäre natürlich gleiches Verhalten mit den Anderen Geräten in FHEM...

Mit dem Metric/Imperial funktioniert nachweislich nicht. Wenn ich das in EEPROM wieder auf FF setze und das Überschreiben unterdrücke (das ist dann egal, ob im Sketch oder durch das Unterdrücken von Ausgehenden Message aus dem Modul), dann läufts korrekt. Wenn ein Message von Controller mit 'M' eintrifft, dann geht das System von Imperial aus. Message wird nicht wie gewünscht interpretiert. Das passiert weil Payload-Typ nicht als Byte erkannt wird. Die Methode getByte liefert dann 0 und isMetric = msg.getByte() == 'M' funktioniert natürlich nicht wie gewünscht. Ich versuche zu verstehen, wie PayloadType gesetzt wird.

Folgendes habe ich gefunden:

Code Auswählen Erweitern

uint8_t command_ack_payload;
                                               // 3 bit - Command type   
                                               // 1 bit - Request an ack - Indicator that receiver should send an ack back.
       // 1 bit - Is ack messsage - Indicator that this is the actual ack message.
                                       // 3 bit - Payload data type
und

Code Auswählen Erweitern

typedef enum {
P_STRING, P_BYTE, P_INT16, P_UINT16, P_LONG32, P_ULONG32, P_CUSTOM, P_FLOAT32
} payload;

Ich glaube mittlerweile, dass Gateway ein Fehler hat. Scheinbar nimmt dieser immer Typ P_STRING an, wenn etwas as der Seriellen Schnittstelle kommt. Methode parseAndSend in MyGateway.cpp macht msg.set(value); und value ist als char *value=NULL; definiert. Dann wind eben MyMessage& MyMessage::set(const char* value)  aus MyMessage.cpp aufgerufen und da wird PayloadType P_STRING gesetzt. Kannst Du vielleicht bei Gelegenheit auch mal drauf schauen? Wenn sich meine Vermutung bestätigt, melden wir das Problem an den MySynsors-Entwickler weiter.
Bis dahin funktionier Metric nur, wenn man I_CONFIG Message nicht beantwortet.

So, heute fallen mir schon die Augen zu... So viel Zeit mit dem blöden Metric/Imperial verbracht. 

[hexenmeister]

Habe für Imperial/Metric-Problem eine (aus meiner Sicht einfache) Lösung implementiert und in MySensors-Forum vorgeschlagen: http://forum.mysensors.org/topic/334/issue-with-temperature-units/19

EDIT:

Es kam schon eine Antwort. Dieser Fehler ist bereits bekannt und korrigiert. Allerdings gibt es in seinem GitHub die Library an zwei Stellen. Eine aktuell, eine nicht. Ich habe natürlich die falsche genommen...

[hexenmeister]

Habe jetzt Unterstützung zum Umbenennen der (technischen) Readings implementiert, angefangen Gedanken über die Default-Attribute zu machen und Constants upgedatet.

Leider kenne ich mich mit dem GIT nicht so gut aus. Habe auf die Schnelle kein pull request hinbekommen (TortoiseGit und ich haben uns wohl gegenseitig nicht verstanden)
Daher sind hier die Patches.

EDIT:
Git-Commando-Zeile lieferte folgendes:

Code Auswählen Erweitern

The following changes since commit 4d2385910c1ed48b9ca2b823b0b58b574192dd07:

  Merge branch 'mysensors' of https://github.com/ntruchsess/fhem-mirror into mysensors (2014-10-19 01:11:35 +0200)

are available in the git repository at:


  https://github.com/hexenmeister/MyFHEM.git mysensors

for you to fetch changes up to 4d2385910c1ed48b9ca2b823b0b58b574192dd07:

  Merge branch 'mysensors' of https://github.com/ntruchsess/fhem-mirror into mysensors (2014-10-19 01:11:35 +0200)

Kannst Du damit was anfangen?

[ntruchsess]

danke für die Patches. Ich bin leider erst gerade eben dazu gekommen reinzuschauen (musste gestern und Heute was an meiner Baustelle machen, nächste Woche wäre die Nachttemperaturen wohl schon zu tief).

Das mit dem Pull-request geht so: Du musst das Repository auf Github selbst clonen und dann Deine Änderungen in Dein geclontes Repository pushen. Der Pull-request wird dann auf Github selbst erstellt und hat mit Deinem lokalen Repository nichts mehr zu tun.

Ich hab Deine Patches gerade mal händig eingespielt. Damit Du das mit dem Pull-request besser verstehst hab ich Deine Änderungen bei mir in den 'mysensors_alex'-branch gepusht und dazu einen Pull-request gegen den 'mysensors'-branch erstellt. Das schöne daran ist, dass man in dem Pull-request alle Differenzen sieht und jede Zeile kommentieren kann (sozusagen 'am lebenden Objekt...')

Das Attributgesteuerte Mappen der Readings könnte man eigentlich doch auch mit UserReadings machen? Dann bräuchte man gar keinen eigenen Code im Modul, es würden die passenden Default-Attribute reichen.

Gruß,

Norbert

[hexenmeister]

Theoretisch habe ich des mit dem PullRequest (glaube ich) verstanden Werde mir heute abend genauer ansehen.

Über UserReadings habe ich auch schon nachgedacht, bin aber zu der Meinung gekommen, dass das nicht das gleiche ist. Damit kann man die bestehenden Readings kopieren. Ich wollte diese jedoch ersetzen. Ich denke, das ist im Interesse der Benutzer, dass die Benennung mit anderen Modulen homogen ist. Nach Möglichkeit sollten sie auch menschenlesbar sein. Die derzeitigen Namen sind mir zu technisch, daher würde ich die am liebsten ganz ausblenden können, unter andern damit sie auch nicht im Log landen (klar, kann man verhindern, aber das ist wieder Zusatzaufwand). Da befand ich die Lösung mit dem 'Ummappen' für ein gangbaren Kompromis.

Grüße,

Alexander

[ntruchsess]

Wenn die technischen Namen ganz verschwinden sollen, dann muss man das Mapping auch im Code festlegen, sonst taucht es im Attribut ja doch wieder auf

Bevor ich mich dessen annehme habe ich aber erst mal noch genug Arbeit damit MYSENSORS_NODE und MYSENSORS_SENSOR in ein einziges Device MYSENSORS_DEVICE zusammenzuführen.

Gruß,

Norbert

[hexenmeister]

sonst taucht es im Attribut ja doch wieder auf

... was für die Custom-Werte bei MySensors wohl der einzige Wert sein wird, einen sinvollen Namen zu vergeben...

[ntruchsess]

für die Custom-variablen (V_VAR1 ff) hast Du natürlich recht, die kann man nicht hardcoded mappen. Muss ich mir noch mal genauer durch den Kopf gehen lassen, wie man das einerseits flexibel, andererseits nicht unnötig kompliziert bzw. mit unnötig vielen Attributen macht.

Ich hab jedenfalls erst mal MYSENSORS_NODE und MYSENSORS_SENSORS in MYSENSORS_DEVICE zusammengefasst. Funktioniert vom Grundsatz her schon mal, Ist aber nicht ganz so weit, wie die vorherige Lösung (das Autocreate beschränkt sich auf das Anlegen des Devices ohne weitere Konfiguration für die representierten Sensoren/Aktoren - die dafür vorgesehene Methode onPresentationMessage ist aktuell noch leer). Code im branch mysensors_unified:
00_MYSENSORS.pm
10_MYSENSORS_DEVICE.pm
die anderen Dateien (lib/Device/MySensors/...) unverändert...

als Beispiel mal eine Konfiguration für den RelayWithButtonActuator.ino, die den Zustand bidirektional auf die STATE-werte 'on/off' abbildet (damit kann man den Aktuator sowohl aus der Weboberfläche heraus direkt schalten, als auch die sensorseitige Zustandsänderung (Schalten per Button am Arduino) direkt auf der Oberfläche visualisiert bekommen):

Code Auswählen Erweitern


define gateway MYSENSORS /dev/ttyUSB0@115200
attr gateway stateFormat connection
define node MYSENSORS_DEVICE 245
attr node IODev gateway
attr node setCommands on:LIGHT_1:1 off:LIGHT_1:0
attr node stateFormat {ReadingsVal("node","LIGHT_1",0) ? "on" : "off"}


Das mit dem Mapping habe ich da noch nicht reingearbeitet, erst muss die Basis 'rund' laufen

Gruß,

Norbert