Mysensors Temperatursensor und das ID Feld

[Beta-User]

Ich hatte es in Präsentation, der Teil läuft nach Setup und wenn Präsentation durch ist, dann kommt ein registrieren.

Die 2.0.0 hat an der Stelle einen Bug, siehe hier:
https://github.com/mysensors/MySensors/issues/514

An sich hätte es gehen sollen, wenn die Info in der setup()-Routine drin ist. Das war m.E. mit einer der features, die man durch die Trennung von setup() in before() und setup() erreichen wollte. (siehe hier: https://github.com/mysensors/MySensors/releases)

Btw.: an sich wäre es besser, wenn die Info über die HW gleich mit als Kommentar/description übertragen wird (siehe hier:

Code Auswählen Erweitern

void present(uint8_t childSensorId, uint8_t sensorType, const char *description, bool ack);.

Das kann aber FHEM nicht verwerten (?) und würde wohl tiefere Eingriffe in die 10_MYSENSORS-DEVICE.pm erforderlich machen. Damit könnte man aber die nummerische Benennung durch die HW-ID ersetzen, wenn sie mit übertragen würde. Wäre klasse, dann wäre nämlich die "Herkunft" der Temperatur-Daten genauso eindeutig wie über OWX und man bräuchte keine Klimmzüge um V_ID herum!

Das anzupassen übersteigt aber meine Kompetenzen...

[Sidey]

Ja, stimmt.
Ob das Tiefe Eingriffe Bedarf weiss ich nicht. Ist halt die Frage, wie FHEM die Beschreibung darstellen soll

[Beta-User]

Na ja, am besten wäre es, statt "temperature" oder "temperature20" gleich die Hardware-Adresse als reading-Namen zu verwenden, (aber nur, wenn sie mit übermittelt wird). Dann bräuchte man sich über die Frage, ob bei jedem Neustart die Sensoren alle noch in der richtigen Reihenfolge sind, keine Gedanken zu machen.

(Und ja, es ist mir bekannt, dass es keine Probleme gibt, solange alle ursprünglich vorhandenen da sind. Bei einem Reboot soll angeblich die ursprüngliche Reihenfolge gleich bleiben. Lustig wird es erst, wenn zwischenzeitlich was passiert. Fehlt z.B. von ursprünglich 8 Sensoren die Nummer 4, dann kann aus 5/8 auch 4/7 werden... Oder es kommt einer hinzu, dann kann er Nummer 1/9 werden usw.).

[Sidey]

Ja, das habe ich mir auch so vorgestellt.

Irgendwo hatte ich ein Beispiel gefunden, da hat jemand eigene IDs im eeprom gespeichert um das Problem zu umgehen, aber eigentlich ist das auch eher ein Workaround.

[Beta-User]

Ja, das habe ich mir auch so vorgestellt.

Irgendwo hatte ich ein Beispiel gefunden, da hat jemand eigene IDs im eeprom gespeichert um das Problem zu umgehen, aber eigentlich ist das auch eher ein Workaround.

Na ja, den workaround kenne ich bestens : auf meinem Github-Repo findest Du zwei Versionen/Ansätze: direkte Addressierung über ein im Sketch gespeichertes Array und das Verhashen und Speichern im EEPROM ... Beide Versionen funktionieren in der Praxis tadellos seit mehreren Monaten, wenn Du also einen schnellen Fix für "Dein" Problem suchst. Die Array-Version funktioniert nur noch nicht mit den neueren Dallas-libs EDIT: Funktioniert vermutlich (mein Arduino scheint einen Hau zu haben, der letzte Sensor wird abgeschnitten) . Der Stored-ID-Sketch sieht zwar vertrackt aus, ich habe mir aber Mühe gegeben zu erklären, wie er funktioniert und wo was geklaut ist (=>github).

Bin jetzt auf 2.0.1, da funktioniert das übrigens tadellos mit setup() (Wenn man das GW auch auf 2.0.1 bringt )
EDIT: irgendwie wollte das GW nicht dauerhaft

@Hauswart: Sketch (Einfaches Sende ID) ist auch auf github, kannst ihn nach optischer Anpassung gerne zu den Beispielsketchen bei MySensors-Contrib mit einchecken.

Gruß,

Beta-User 

[Sidey]

ok Fehler gefunden.... argh


Ich hab nicht den Inhalt von deviceAddress in Hex umgewandelt, sonder die Adresse davon... Arghh:
Damit ist der String auch nur noch 16 Zeichen, wie es zu erwarten ist.

Code Auswählen Erweitern


snprintf(addr, 18,"%02X%02X%02X%02X%02X%02X%02X%02X",
deviceAddress[0], deviceAddress[1], deviceAddress[2], deviceAddress[3],
deviceAddress[4], deviceAddress[5], deviceAddress[6], deviceAddress[7]); //snprintf


[Hauswart]

Ich war leider das Wochenende über unterwegs und kann mich erst jetzt wieder durch die Beiträge arbeiten