Integration von MySensors in FHEM geplant?

Hauswart · 20 April 2016, 11:21:18

Zitat von: joe_re am 20 April 2016, 10:20:00
Hallo Hauswart,

das mit der eindeutigen Zuordnung der einzelnen Sensoren ist echt eine harte Nuss; ich habe damals die Lösung über das Array gewählt, weil ich keine Möglichkeit gesehen habe, auf andere Weise sicherzustellen, dass der von FHEM "gesehene" Wert auch zum "richtigen" Sensor paßt.

Nachdem ich jetzt gestern noch einige Tests gemacht habe und meine damalige Link-Liste durchgesehen habe, folgende Gedanken:

- Zuordnung innerhalb FHEM:
Hier scheint FHEM derzeit mit anderen Infos außer der Temperatur nichts anfangen zu können. Jedenfalls konnte ich auch bei mir die in Deinem Code nach jeder Messung übermittelte ID nirgendwo wiederfinden. Dann habe ich noch versucht, das im Rahmen der Presentation mögliche Kommentarfeld zu nutzen (nicht mal ein fester Text-String war in FHEM wiederzufinden, und einen Char* aus der Adresse machen, ist auch nicht so einfach...).
Aber vielleicht gibt es eine einfache Möglichkeit, das in das MYSENSORS-DEVICE-FHEM-Modul mit reinzubasteln (dann bliebe neben der Formatumwandlung "nur" noch die Frage, wie man das Kommentarfeld auswertbar macht; hier könnte man vielleicht aber auch den Reading-Namen auf den übermittelten Kommentar ändern, wenn ein solcher vorhanden ist; was ja nicht alle für Mysensors denkbaren Temperatursensoren erforderlich ist bzw. Sinn macht)

- Zuordnung auf der Arduino-Seite:
Hier kann man im Standard-Sketch m.E. nie sicher sein, ob sich die interne Nummerierung geändert hat, wenn "irgendwas" passiert (vom einfachen Reboot über den Ausfall einzelner Sensoren oder das Anklemmen neuer usw.).
Eine Lösung dazu wäre die mit dem starren Array, was aber erfordert, dass man vorher mühsam die Adressen ausliest und dann bei der Montage noch weiß, welche Adresse zu welchem der Kabel gehört. Umständlich eben.
Hier hat LeoDesigner einen interessanten Ansatz gewählt, nämlich dynamisch ein Array zu bilden und im EEPROM zu speichern. Das dürfte andere Nachteile haben, macht es aber dahingehend einfach, dass man "nur" jeweils die Sensoren einen nach dem anderen anschließt und den Arduino jeweils zwischendurch neu startet. Den entsprechenden Sketch (nicht getestet) gibt es unter https://github.com/leodesigner/mysensors-arduino/blob/master/DallasTemperatureSensor_Recall/DallasTemperatureSensor_Recall.ino

Hoffe, das führt weiter.

Kurz als Antwort, die ID wird in FHEM übertragen! Hatte ich oben vergessen zu erwähnen.

Bitte beim entsprechenden Device (autocreate) folgendes eingeben:

Code Auswählen

attr MYSENSOR_104 userreading mapReading_id 0 id
Leider muss man derzeit die ID-Readings (noch) von Hand anlegen. Das Problem ist leider, dass die Beziehung Reading <=> Sensor nicht immer identisch ist, sondern variiert. Und da fehlt mir derzeit ein Ansatzpunkt wie ich weiter verfahren soll/muss.

Beta-User · 20 April 2016, 11:54:47

Ok, aber was heißt das, dass die Beziehung Reading <=> Sensor variiert?

Bei einem Neustart des Arduino oder auch im laufenden Betrieb?

Was mir auch nicht so richtig klar ist, ist der Umstand, wieso die MYSENSORS-API das mit der ID überhaupt in der Form vorsieht. M.E. macht es eigentlich wenig Sinn, immer dieselben Informationen zu verfunken (und das nicht ein einziges Mal im Rahmen der Presentation zu erledigen und gut ist). Das wäre erst anders, wenn sich die interne Nummerierung der einzelnen Sensoren wirklich im laufenden Betrieb hin und wieder ändern würde?!?

Wenn das wirklich der Fall wäre, sollte man m.E. beide Ansätze kombinieren, also die interne Zuordnung (bereits) auf Arduino-Ebene verstetigen und dann die erweiterten Infos innerhalb FHEM nur noch zur Prüfung bzw. Ersteinrichtung zu benutzen.

Was die Erfahrungen mit meinem Array-Code angeht: Ich habe auch bei Neustarts und längerem Betrieb (jedenfalls soweit ersichtlich) keine Probleme, dass ich den "falschen" Meßwert in FHEM benutzt hätte; meine Graphen sehen jedenfalls soweit plausibel aus.

Hauswart · 20 April 2016, 13:22:39

Zitat von: joe_re am 20 April 2016, 11:54:47
Ok, aber was heißt das, dass die Beziehung Reading <=> Sensor variiert?

Bei einem Neustart des Arduino oder auch im laufenden Betrieb?

Was mir auch nicht so richtig klar ist, ist der Umstand, wieso die MYSENSORS-API das mit der ID überhaupt in der Form vorsieht. M.E. macht es eigentlich wenig Sinn, immer dieselben Informationen zu verfunken (und das nicht ein einziges Mal im Rahmen der Presentation zu erledigen und gut ist). Das wäre erst anders, wenn sich die interne Nummerierung der einzelnen Sensoren wirklich im laufenden Betrieb hin und wieder ändern würde?!?

Wenn das wirklich der Fall wäre, sollte man m.E. beide Ansätze kombinieren, also die interne Zuordnung (bereits) auf Arduino-Ebene verstetigen und dann die erweiterten Infos innerhalb FHEM nur noch zur Prüfung bzw. Ersteinrichtung zu benutzen.

Was die Erfahrungen mit meinem Array-Code angeht: Ich habe auch bei Neustarts und längerem Betrieb (jedenfalls soweit ersichtlich) keine Probleme, dass ich den "falschen" Meßwert in FHEM benutzt hätte; meine Graphen sehen jedenfalls soweit plausibel aus.

Dies wären Punkte die man meiner Meinung nach genau testen müsste. Habe auch schon mit Tests begonnen. Im laufenden Betrieb verändern sich die IDs nicht (ausser wir fügen einen neuen Sensor hinzu, dann wird dieser Wert logischerweise auch übertragen)

1. Start:
ID1 = Sensor1
ID2 = Sensor2

Laufender Betrieb
ID1 = Sensor1
ID2 = Sensor2

Laufender Betrieb, Sensor hinzufügen
ID1 = Sensor1
ID2 = Sensor2
[neu] ID3 = Sensor3

Laufender Betrieb, Sensor 2 entfernen
ID1 = Sensor1
[ID2] wird nicht mehr aktualisiert
ID3 = Sensor3

Bei welchem Event, die IDs neu durchgezählt werden ist meine ich nach einem Reset. Dann werden nach Sensor-ID aufsteigend die IDs befüllt (siehe mein Screenshot).

Beispiel von oben Laufender Betrieb, Sensor hinzufügen
ID1 = Sensor1 - ID: 1001
ID2 = Sensor2 - ID: 1010
[neu] ID3 = Sensor3 - ID: 1002

1. Start nach Reset mit den 3 Sensoren:
ID1 = Sensor1 - ID: 1001
ID2 = Sensor3 - ID: 1002
ID3 = Sensor2 - ID: 1010

Zitat von: joe_re am 20 April 2016, 11:54:47
Was mir auch nicht so richtig klar ist, ist der Umstand, wieso die MYSENSORS-API das mit der ID überhaupt in der Form vorsieht. M.E. macht es eigentlich wenig Sinn, immer dieselben Informationen zu verfunken (und das nicht ein einziges Mal im Rahmen der Presentation zu erledigen und gut ist). Das wäre erst anders, wenn sich die interne Nummerierung der einzelnen Sensoren wirklich im laufenden Betrieb hin und wieder ändern würde?!?

Der Vorteil ist, ich kann im laufenden Betrieb neue Sensoren anschliessen

Zitat von: joe_re am 20 April 2016, 11:54:47
Wenn das wirklich der Fall wäre, sollte man m.E. beide Ansätze kombinieren, also die interne Zuordnung (bereits) auf Arduino-Ebene verstetigen und dann die erweiterten Infos innerhalb FHEM nur noch zur Prüfung bzw. Ersteinrichtung zu benutzen.

Was die Erfahrungen mit meinem Array-Code angeht: Ich habe auch bei Neustarts und längerem Betrieb (jedenfalls soweit ersichtlich) keine Probleme, dass ich den "falschen" Meßwert in FHEM benutzt hätte; meine Graphen sehen jedenfalls soweit plausibel aus.

Der Array ist sicherlich eine saubere Sache, aber man muss natürlich händisch den Sketch anpassen und bei jedem neuen Sensor wieder erweitern.

Beta-User · 20 April 2016, 14:48:55

Jetzt bin ich erst mal beruhigt, dass das in etwa so statisch ist, wie ich vermutet hatte

.

Zitat von: Hauswart am 20 April 2016, 13:22:39
Der Vorteil ist, ich kann im laufenden Betrieb neue Sensoren anschliessen

Dafür sehe ich allerdings jetzt nicht so die große Notwendigkeit; ich habe bisher eher versucht, alles stromlos zu machen, wenn ich irgendwas umkable

.... Und dann wird doch eigentlich auch bei Presentation() die max. Anzahl an Sensoren vergeben/abgefragt und an den Controller übermittelt? Wird das wiederholt, wenn im laufenden Betrieb was geändert wird?

Zitat von: Hauswart am 20 April 2016, 13:22:39
Der Array ist sicherlich eine saubere Sache, aber man muss natürlich händisch den Sketch anpassen und bei jedem neuen Sensor wieder erweitern.

Genau hier setzt - jedenfalls wenn ich das richtig verstanden habe - der Sketch von LeoDesigner https://github.com/leodesigner/mysensors-arduino/blob/master/DallasTemperatureSensor_Recall/DallasTemperatureSensor_Recall.ino (nicht meiner) an: man muß die Adressen der einzelnen Dallase gar nicht vorher schon kennen, diese werden beim Start der Node automatisch und "on-the-fly" erfaßt und - so dort noch nicht vorhanden - (verhasht) ins EEPROM geschrieben. Der weitergehende Trick scheint zu sein, dass dann auch die Child-Sensor-ID nach der Position im EEPROM-Array vergeben wird, sich maW. also gerade nicht mehr ändert, wenn äußere Änderungen (z.B. mehr oder weniger Dallas-Sensoren) stattfinden. Nicht mehr besetzte Sensor-CHILD-ID's werden ausgelassen (nach 1 kommt 3, wenn es 2 nicht mehr gibt, ein neuer Sensor wäre dann 4), und zwar auch über Resets und Neustarts hinaus.
Das paßt jedenfalls so lange, bis man die Daten im EEPROM löscht oder das Array voll ist oder überläuft (häufige Wechsel oder so).

Wenn das tatsächlich funktioniert, sollte eigentlich recht pragmatisch gewährleistet sein, dass sich hinter der FHEM bekannt gemachten Child-ID jeweils immer dieselbe Hardware-ID verbirgt.
Vielleicht teste ich das heute Abend mal aus; das Thema hat mich auch so lange beschäftigt, dass es einfach super wäre, auch mal was beizutragen, was anderen hilft, Kopfzerbrechen und mangelnden WAF zu vermeiden... $:-\$

Hauswart · 20 April 2016, 15:00:16

Zitat von: joe_re am 20 April 2016, 14:48:55
Genau hier setzt - jedenfalls wenn ich das richtig verstanden habe - der Sketch von LeoDesigner https://github.com/leodesigner/mysensors-arduino/blob/master/DallasTemperatureSensor_Recall/DallasTemperatureSensor_Recall.ino (nicht meiner) an: man muß die Adressen der einzelnen Dallase gar nicht vorher schon kennen, diese werden beim Start der Node automatisch und "on-the-fly" erfaßt und - so dort noch nicht vorhanden - (verhasht) ins EEPROM geschrieben. Der weitergehende Trick scheint zu sein, dass dann auch die Child-Sensor-ID nach der Position im EEPROM-Array vergeben wird, sich maW. also gerade nicht mehr ändert, wenn äußere Änderungen (z.B. mehr oder weniger Dallas-Sensoren) stattfinden. Nicht mehr besetzte Sensor-CHILD-ID's werden ausgelassen (nach 1 kommt 3, wenn es 2 nicht mehr gibt, ein neuer Sensor wäre dann 4), und zwar auch über Resets und Neustarts hinaus.
Das paßt jedenfalls so lange, bis man die Daten im EEPROM löscht oder das Array voll ist oder überläuft (häufige Wechsel oder so).

Wenn das tatsächlich funktioniert, sollte eigentlich recht pragmatisch gewährleistet sein, dass sich hinter der FHEM bekannt gemachten Child-ID jeweils immer dieselbe Hardware-ID verbirgt.
Vielleicht teste ich das heute Abend mal aus; das Thema hat mich auch so lange beschäftigt, dass es einfach super wäre, auch mal was beizutragen, was anderen hilft, Kopfzerbrechen und mangelnden WAF zu vermeiden... $:-\$

Jetzt habe ich es verstanden, oder vorhin überlesen

Muss mir in einer ruhigen Minute den Sketch mal genauer anschauen und eventuell auf meinen Adaptieren. Das würde natürlich dazuführen, dass wir eine 1:1 Beziehung haben, welche wir ja möchten

Edit: Wann genau Presentation durchlaufen wird, weiss ich leider derzeit auch nicht genau... Habe dazu keine Dokumentation gefunden.

Beta-User · 20 April 2016, 15:24:38

Beteilige mich gerne, v.a. am Testen!
Ist vermutlich besser, wie wenn ich versuche zu coden, es ist schließlich schon mühsam (und fehleranfälltig) genug, meine Gedanken zu vorhandenem Code verständlich auszudrücken...

Vielleicht noch eines in Ergänzung zu dem "Overflow-"Thema im EEPROM: Irgendwo hatte ich auch mal eine ähnlichen, aber viel älteren Sketch (nicht Mysensors) gesehen, der dann auch noch gecheckt hat, ob es noch freien Platz im EEPROM hat und dann nicht mehr aktiv genutzte Teile dieses Arrays mit neuen Sensor-IDs befüllen konnte. Das wäre dann die eierlegende Wollmilchsau, aber leider finde ich den Code nicht wieder

.

Dann würde ich noch anregen, die (einmalige) Übermittlung der ID in den Presentation()-Teil zu nehmen, ggf. im Rahmen einer eigenen Schleife

?

Beta-User · 20 April 2016, 22:33:26

Das sieht eigentlich gar nicht schlecht aus!

~~So, getestet und: überfordert...~~

Den Sketch von leodesigner in der Ausgangsfassung konnte ich nicht kompilieren, da meine Umgebung neuer ist (Arduino 1.6.7, Mysensors 2.0.0-beta).
Daher habe ich mich doch mal ans Überarbeiten und Zusammenfassen der Code-Varianten (und die EEPROM-bezogenen-Befehle geändert) gemacht, Ergebnis anbei (ACHTUNG: 1W-Anschluß: ich nutze die 5...).

Und die Feststellungen sind sehr gemischt:

Erst mal nur einen Sensor angeschlossen und diesen getauscht: Beide kommen jeweils auf die Child-ID 0 => Mist!!!
Dann habe ich zwei angeschlossen: Beide werden an FHEM übermittelt, die IDs sehe ich auf dem Seriellen Monitor => na ja, wenigstens was...
Dann einen der beiden wieder entfernt ("0"): der Andere bleibt auf der Child-ID 1 => Hurra!!!!

Also: Das Prinzip an sich scheint zu funktionieren, für weitere Tests (mehr Sensoren... habe ich heute abend keine Lust mehr). Fest steht jedenfalls, dass auch das Schreiben/Lesen ins EEPROM noch nicht so ist, wie es sein sollte; ich würde tippen, dass der Hash für den ersten Sensor ins digitale Nirvana wandert und nicht ins EEPROM. Vielleicht hat ein wirklicher Experte da mehr Durchblick?!?

Im Bette liegend kam mir dann die Vermutung, dass meine Erwartung schlicht zu hoch gewesen sein dürfte; das ganze funktioniert vermutlich, solange man die Zahl der Sensoren immer weiter erhöht, aber nicht, wenn man tauscht.
Die Initiierungs-/Speicherlogik muß nach meinem Geschmack um eine "Suche den ersten freien Platz im EEPROM bzw. wenn das nicht (mehr geht), den ersten nicht mehr benutzen Platz" erweitert werden.

Wenn ich das richtig sehe, könnte man dafür die vorhandene Logik bei Setup() erweitern, indem man erst wirklich das ganze Array ts_sopt["i"] auf false setzt (nicht nur bis numSensors), dann aber nicht nur auf vorhandene Hardware prüft, sondern darauf, ob der Platz noch auf "00" steht (keine Ahnung, was dort steht, wenn frisch geflashed wurde?); die (jetzige) Schleife für vorhandene HW würde man dann nur nutzen, wenn alle Plätze im EEPROM belegt sind???

Ach so, das mit "attr MYSENSOR_106 userreading mapReading_id 0 id" ging gar nicht, die Fassung "attr MYSENSOR_106 userReadings mapReading_id 0 id" half auch nicht wirklich).

Beta-User · 21 April 2016, 09:50:03

Nachdenken hilft manchmal (hoffentlich):
Mittlerweile habe ich den Eindruck, dass der Sketch macht, was wir von ihm erwarten (und was leodesigner auch reingeschrieben hat) und meine Erwartungen schlicht an den Erfordernissen vorbei sind:
Entweder
- man nimmt einen Sensor ganz raus => dann macht es Sinn, die Nummerierung der übrigen nicht zu ändern (müßte so sein)
- man ersetzt einen Sensor => in der Regel soll dieser dann an die Stelle des nicht mehr vorhandenen treten (scheint so zu sein, allerdings habe ich das gestern noch als Bug wahrgenommen

...)
- man macht einen weitern, neuen dazu => hinten weiternummerieren (dürfte auch so sein)

Bin mal auf Eure Testergebnisse gespannt...

OK, jetzt werde ich mutig !

Unter http://hacks.ayars.org/2012_06_01_archive.html habe ich noch was ähnliches gefunden. Vorgehen dort: Erst alle Adressen erfassen im EEPROM, dann in der Reihenfolge auslesen, wie im EEPROM gespeichert (dort in zwei Sketchen, die gesamte Logik sollte aber mit überschaubarem Aufwand in den gestern gestrickten einzubauen sein).

Mein Gedanke jetzt: wäre es nicht besser, auf den Umweg mit der Hash-Wert-Bildung zu verzichten und das auch so zu machen??? Das lesen dauert u.U. etwas länger, der Platzbedarf im EEPROM ist höher, dafür entfällt die Umrechnerei und die Reihenfolge richtet sich nicht mehr nach den Verhältnissen auf dem Bus, sondern nach dem EEPROM. Damit sollte es eigentlich einfacher sein, die Infos zu "belegt" und "vorhanden" klarer zu sortieren (weil der Durchlaufindex i identisch bleiben kann).

Ich würde mir das so vorstellen, dass die nicht physisch vorhandenen, aber gespeicherten Adressen schlicht nicht ausgelesen/übersprungen werden (da ist ts_spot["i"] ja falsch).

Meinungen dazu?

KarlHeinz2000 · 21 April 2016, 21:46:57

Kann man irgendwie umgehen, dass FHEM automatisch eine 1 hinter die setreading Definition schreibt?

Code Auswählen


attr MYSENSOR_102 setReading_power11 1
attr MYSENSOR_102 setReading_power12 1
attr MYSENSOR_102 setReading_power13 1
attr MYSENSOR_102 setReading_power14 1
attr MYSENSOR_102 setReading_power15 1

Ich möchter gern beliebige Werte senden...
Ich kann die Einsen löschen, dann ist alles gut. Aber nach einem restart sind sie wieder da

Bei >20 attr pro Device ist das ganz schön lästig

Beta-User · 22 April 2016, 19:51:41

Nochmal zu dem Dallas-Index:

Anbei ein modifizierter Sketch mdB. um heavy testing!

Einige Anmerkungen sind schon im Code enthalten. Das Prinzip ist, beim ersten Start die Hardwareaddressen in einer verkürzten, aber eindeutigen Form im EEPROM (also fest) zu speichern. Einmal dort, überleben sie nicht nur Neustarts, sondern sogar auch Modifikationen des Sketches und werden dann immer wieder als Child-IDs verwendet. Da ich es sowieso schon immer verwirrend fand, dass auch bei mehreren vorhandenen Sensoren binär gezählt wird (also temperature für den ersten Sensor, temperature1 für den zweiten, habe ich allerdings die Child-IDs um "1" erhöht, dann lässt es sich auch einfacher abfragen, ob wir den Sensor kennen oder nicht.

Bei jedem Neustart wird dann geprüft, ob die Adresse bekannt ist (also im EEPROM vorhanden). Wenn ja, benutzen wir wieder die gleiche Child-ID wie das letzte Mal (über ein Array). Kennen wir einen Sensor noch nicht, nutzen wir
- bei einem Tausch den Platz des getauschten im EEPROM zum Speichern, ansonsten
- (weiterer Sensor) den ersten nicht benutzten (maW. wird der zusätzliche dann der sein, der bei FHEM die höchste Nummer hat).

Das lädt zwar eventuell dazu ein, einen Sensor nach dem anderen einzubauen (dann weiß man, welchen man wo verbaut hat), ich würde aber eher empfehlen, erst mal die maximal angedachte Menge Sensoren anzuschließen (erklär ich weiter unten dann, warum). Dann kann man jeden einzeln dazubauen, und sieht dann in FHEM, unter welcher Nummer er sich meldet (alle anderen aktualisieren sich ja nicht bzw. die bekanntne kann man sich ja notieren).

Will man alles auf Anfang setzen, kann man einfach alle Dallase entfernen (das sollte man aber wohl tunlichst nach der Ersteinrichtung verhindern, indem man diese Option deaktiviert).

Meine Vermutung ist, dass die die Dallas-Library grundsätzlich den Bus so ordnet, dass die niedrigste HW-ID als erstes abgefragt wird usw. Daher ist der Hintergrund obiger Empfehlung, einmal mit allen Sensoren zu starten: Stimmt das, werden die ID's auch bei einem Löschen des EEPROM wieder in der gleichen Reihenfolge vergeben und gespeichert; das erspart das mühsame Suchen nach Auswirkungen in FHEM (wo ist welcher Meßwert verwendet...). Allerdings nur, wenn die Gesamtzahl unverändert ist

.

Ansonsten spuckt der Sketch einiges an Debug-Info über die Konsole aus, was sich ebenso deaktivieren lassen sollte wie die Übermittlung der HardwareID auf die entsprechende Child-ID. Was mir (noch) nicht gelingen will, ist die Nutzung der Kommentar-Option von Mysensors, um die Hardware-ID gleich bei der Initialisierung mit zu übermitteln.

Wenn das aber tatsächlich alles funktioniert wie gedacht, sollte das eigentlich kein Problem mehr sein (wäre nur eine human-readable Debug-Hilfe, wenn doch mal alles durcheinandergehen sollte).

Viel Freude damit!

Beta-User · 25 April 2016, 23:03:50

So, und nochmal eine Überarbeitung des Sketches zur Festnagelung der Dallas-IDs.

Änderungen:
- Bugfix betr. die Indexierung neuer Hardware, wenn man mehr als einen auf einmal dazufügt

- Rückkehr zur Nutzung der Mysensors-Speicherfunktion statt direktem Zugriff auf irgendwelche EEPROM-Adressen $:-\$
- Die erste Child-ID für die Dallase kann frei vergeben werden (sollte v.a. beim Zusammenbasteln mit Relays helfen, Probleme zu vermeiden)

.
- Mehr Unterroutinen zur Verbesserung der Übersichtlichkeit

Enjoy

r_knipp · 01 Mai 2016, 23:28:37

Hallo,

ich habe mal den IR Sender/Empfänger in Betrieb genommen. (https://www.mysensors.org/build/ir)
Hat den vielleicht schon mal jemand ausprobiert?
Habe mir mit nem Nano ein Serial Interface gebaut und den Sensor auch mit nem Nano aufgebaut.
Scheint soweit zu funktionieren. Allerdings bietet der Sensor keine bisher gemappten readings.
Die empfangenen IR-Codes werden als Rohdaten in V_VAR1 gespeichert.
Wie komme ich denn in FHEM jetzt an die Daten und wie kann ich IR-Codes senden?
Der Sketch bietet anscheinend auch ein Decoding bekannter Codes an aber ich bekomme das nicht kompiliert wenn ich den Teil einkommentiere.

Edit:
Kleine Anmerkung. Toll wäre bei diesem Sensor natürlich eine Funktion zum IR-Code anlernen/speichern und zum späteren Versenden auf ein Command mappen.

Beta-User · 02 Mai 2016, 11:06:44

Um hier nicht weiter Neuigkeiten zu dem Dallas-Index-Sketch zu posten, ist die aktuelle Fassung und ein weiterer Beispielsketch auf Basis eines manuell zu editierenden Arrays bei github unter https://github.com/rejoe2/MySensors-Dallas-Address-ChildID-Consistency abgelegt. Kommentare, Anregungen usw. sind willkommen

.

Beta-User · 02 Mai 2016, 11:07:02

Hallo r_knipp,

Glückwunsch zur erfolgreichen Inbetriebnahme des IR-Sensors!
Da ich gesehen habe, dass Du schon länger auch an dem Thema IR-Sender dran bist: Warum über MySensors und nicht die ESP-Lösung??? Das wäre nach meinem Gefühl eigentlich der schnellere Weg, oder?

Zu MySensors:
Die Node an sich scheint zu funktionieren, sie wird ja in FHEM angezeigt. Üblicherweise sollte dann noch ein neues Reading auftauchen (aber auch erst dann), wenn der Sensor etwas erkennt. Passiert denn in FHEM irgendwas, wenn Du mit einer Fernbedienung "spielst"? Was für eine hast Du denn (RC5/RC6 wäre vermutlich als Start ganz sinnvoll)?

r_knipp · 02 Mai 2016, 11:31:19

Zitat von: joe_re am 02 Mai 2016, 11:07:02
Hallo r_knipp,

Glückwunsch zur erfolgreichen Inbetriebnahme des IR-Sensors!
Da ich gesehen habe, dass Du schon länger auch an dem Thema IR-Sender dran bist: Warum über MySensors und nicht die ESP-Lösung??? Das wäre nach meinem Gefühl eigentlich der schnellere Weg, oder?

Ja? Meinst du das ist der schnellere Weg? viegeners Lösung mit Arduino Mini könnte ich nochmal austesten. Hatte mich da irgendwie auf die ESP only Version versteift und die lief ja noch nicht als Sender/Empfänger.
Bei mysensors hatte ich die Hoffnung auf Aufbauen, anschließen und funktioniert. Aber da habe ich mir wohl mal wieder einen Sonderling rausgesucht.
Die Lösung mit mysensors würde ich ehrlich gesagt WiFi auch vorziehen. Aber ich denke, ich werde es heute Abend einfach mal mit dem ESP am Arduino ausprobieren.

Aber vielleicht hat ja trotzdem jemand mit ausreichend Know How Lust das Teil funktionsfähig zu machen.
Im Prinzip würde es ja reichen wenn man V_VAR1 auslesen könnte und das ganze dann unter einem Command speichern kann.

Zitat von: joe_re am 02 Mai 2016, 11:07:02
Zu MySensors:
Die Node an sich scheint zu funktionieren, sie wird ja in FHEM angezeigt. Üblicherweise sollte dann noch ein neues Reading auftauchen (aber auch erst dann), wenn der Sensor etwas erkennt. Passiert denn in FHEM irgendwas, wenn Du mit einer Fernbedienung "spielst"? Was für eine hast Du denn (RC5/RC6 wäre vermutlich als Start ganz sinnvoll)?

Ich habe bisher eine Fernbedienung von einem Panasonic DVD-Player getestet. Über die serielle Schnittstelle kommt halt der Code in Rohform.
In FHEM passiert gar nichts. Sicher dass da auch ein neues Reading auftauchen sollte? Bei den üblichen Sensoren wie Temp und Luftfeuchte bestimmt aber V_VAR1 ist nicht auf ein Reading gemappt. Denn wenn ich das richtig verstanden habe sind doch bestimmte Variablen, z.B. V_TEMP beim Temp-Sensor, auf entsprechende Readings gemappt, die dann bei Vorhandensein der Variablen angelegt werden.