ein Server zwei Gateways

[Markus.]

Hallo Zusammen,

habe auf einem Server zwei Gateways definiert. Eins für RFM Nodes und das zweite für NRF24L01 Nodes. Funktioniert auch soweit ganz gut bisher. Jedenfalls konnte ich, bis auf die "Standard Zickigkeit" der NRF Nodes nichts feststellen. Das NRF Gateway wurde nach dem RFM Gateway im Server definiert. Nach einem Neustart der Nodes haben diese sich auch schön durch Autocreate in FHEM angelegt. Nun aber zu einem Punkt der mir nich nicht gefällt... Am RFM Gateway (erstes definiertes) habe ich einen Sensor, der ja Node 0 ist. Das zweite Gateway hat zwar keinen Sensor den es präsentieren kann, versucht aber bei jedem Start das Versions-Attribut des ersten Gateways-Nodes zu überschreiben. Ist halt unschön ...
Kann an eigentlich per Attribut, z.b. first-SensorID, bestimmen das nicht Node0 sondern Node1 der erste ist oder hat das keinen Einfluss auf den Gateway-Node...
Nun ja will halt das Gateway nicht neu flashen. Meine im Kopf zu haben das es dafür ein define gibt was Default eingeschaltet ist. Zur Not könnte man ja den presentation Teil rausholen aus dem Sketch. Aber wollte erstmal fragen ob es auch anders geht.

Gruß

Markus



 

[Beta-User]

Hmmm, habe das bisher auch nicht im Detail getestet, aber hast du mal versucht, bei einem der GW's eine Node-ID manuell vorzugeben?
Also

Code: [Auswählen]

#define MY_NODE_ID 1in den Code für's "neue" GW einpflegen (vorausgesetzt, die "1" ist noch frei). Die Attribute und Automatismen in FHEM kommen ja erst zum Tragen, wenn die ID noch nicht auf der Node gespeichert ist.

Was sonst noch zu beachten ist: Neue Nodes werden immer bei dem GW angelegt, das zuletzt definiert wurde (also in der cfg weiter hinten steht, so man .cfg nutzt). Da muß man ggf. das IO ändern, sonst kann es auch sein, dass die neue Node unvollständig angelegt wird (nach Anpassung des IO's noch einen Reset der Node machen), und auch Befehle dahin nicht ausgeführt werden können.

[Markus.]

Hi,

ja NodeId 1 ist noch frei, mussich mal testen das neu zu flashen bei Gelegenheit. Das mit dem IODEV ist mir aufgefallen. Halt auch ein wenig unschön, das nicht das IODEV geholt wird von dem die Sensoranmeldung eigentlich erfolgte sondern nach der Definitionsreihenfolge in der cfg vorgegangen wird. Evtl. wäre das was für eine zukünftige Erweiterung des Moduls?
Aber der Anwendungsfall ist ja auch nicht unbedingt die Regel... ;-)

Gruß

Markus