Integration von MySensors in FHEM geplant?

[hexenmeister]

Das es RepeaterModus gibt, wusste ich schon, finde aber mehrere Gateways sauberer, denn weniger Latenz und Funk-Last.

Mehrere Kanäle würden ja bedeuten, dass ich mich bei den Sensoren selbst entscheiden soll, mit welchem Gateway sie empfangen werden können. Da würde ich etwas automatisches wünschen, wie bei HomeMatic z.B.

ich hab erst mal nur 2 nRF24L01 gekauft, da hätte ich besser gleich richtig zulangen sollen.

Mir gefällt das System doch besser, als erwartet. Ich werden noch 10 Stück bestellen.

[fh168]

Das es RepeaterModus gibt, wusste ich schon, finde aber mehrere Gateways sauberer, denn weniger Latenz und Funk-Last.

Mehrere Kanäle würden ja bedeuten, dass ich mich bei den Sensoren selbst entscheiden soll, mit welchem Gateway sie empfangen werden können. Da würde ich etwas automatisches wünschen, wie bei HomeMatic z.B.
Mir gefällt das System doch besser, als erwartet. Ich werden noch 10 Stück bestellen.

Ach nee , hat sich die Anfrage für die Programmierung eines Moduls doch gelohnt.
Wie sieht es denn mit den Störungen im WLAN aus? Hast du etwas davon bemerkt?
Ich zumindest habe keine.

Wann wird es denn eingecheckt?

robin

[ntruchsess]

Aktuell kann man den Sende-/Empfangskanal nur in der MyConfig.h fest einstellen. Natürlich könnte man eine Automatik implementieren, die kostet aber auch wieder Speicher. Kannst Dich ja mal ranmachen, sollte aber optional per #define in der MyConfig.h zu aktivieren sein.

- Ignorieren von ID-Requests wenn inclusion-mode bzw. autocreate nicht aktiv sind ist erledigt.

- requestAck optional am Device auch. Ist 'additiv' - wenn es am Gateway gesetzt ist, gilt es für alle Nodes unabhängig davon, ob es am Node selbst auch aktiviert ist. (Um Missverständnisse auszuschließen kann man das Attribut jetzt nur noch auf 1 setzen oder löschen).

- das 'set_XXX'-attribut habe ich in 'setReading_XXX' umbenannt. Finde ich eindeutiger.

- die on/off - Semantik kannst Du per 'attr xxx mapReadingType_LIGHT switch 0:on 1:off' pro Node umdrehen.

@Robin: Mach dich ans Testen und gib Feedback, ob es architekturell bzw. von der Semantik der Attibute her passt, dann checke ich es ein (Bugs kann man immer noch fixen).

Gruß,

Norbert

[hexenmeister]

@Robin
Ich muss gestehen, Störungen gab es keine (die ich merken konnte). Die Qualität des (Billig)Moduls hat mich schon überrascht. Da die Reichweite (für mich auch eher unerwaret) ganz gut ist, werde ich mein GesamtSystem weiter mit diesen Teile erweitern (versuchen), da sie doch etwas billiger sind als meine FRM12b-Teile und es bereits eine brauchbare Firmware existiert.

Die "Multi-Gateway-Fähigkeit" fehlt mir jedoch noch (Stichwort: Ausfallsicherheit und Reichweite), da reichen mir die Repeater Nodes nicht. Ich möchte auch, dass alle Sensoren mit allen Gateways empfangen werden können.
@Norbert: Was hälst Du von der Idee, dass die Nachrichten ignoriert werden, wenn vor max. X Sekunden (eine ?) eine identische Nachricht verarbeitet wurde? Damit könnte man ja die Duplikate sicher erkennen, Nachteile sehe ich auch keine.

Weiterhin wäre wohl sinnvoll, eine PCB entwickeln und fertigen lassen, wo alles einfach drauf gelötet werden kann (wenn man genug davon bestellt, kostet das etwa 1 Euro pro Stück), diese Fummelei mit den Kabelpeitchen nervt...

Klasse, dass die gestern gefundenen Probleme schon gefixt sind, danke! Ich werde heute Abend wieder testen. Wenn nichts mehr ist und die Doku verständlich ist, kann man IMHO auch einchecken. Wir brauchen aber schon nach Möglichkeit 1-2 weitere Tester mit anderen Konfigurationen, Vorstellungen und Einsatzszenarien.

Grüße,

Alexander

[ntruchsess]

In Bezug auf Reichweitenerhöhung durch Einsatz mehrerer günstig platzierter Gateways sehe ich da keine Probleme. Die Sensoren müssten einfach dem räumlich näher liegenden Gateway per IODev zugeordnet werden. Das Gateway ignoriert Nachrichten, für die es keinen per IODev zugeordneten client findet. Der Autocreate-mechanismus müsste noch das IODev-attribut direkt zuweisen, damit die neu angelegte MYSENSORS_DEVICE-instanz nicht beim anderen Gateway landet.
Der ID_Request ist etwas problematisch, weil jede MYSENSORS-modul instanz davon ausgeht die IDs frei vergeben zu können. Das wäre mit einem Attribut 'last-sensorid' in den Griff zu kriegen, dann könnte man jedem Gateway einfach einen ID-range zur Vergabe zuweisen.
Die Sensoren müsste man natürlich geziehlt anlernen (den inclusion-mode also immer nur bei einem Gateway anschalten).
Lästig ist, dass die Sensoren kein Löschen der gesetzten ID per Knopfdruck (analog zum inclusion-mode-button am Gateway) vorsehen. Hat ein Sensor erst mal eine ID, die nicht im Range des gewünschten Gateways liegt, dann kann der Sensor zwar per IODev diesem Gateway zugeordnet werden, man muss aber beim Anlernen weiterer Sensoren damit rechnen ID-Dubletten zu erzeugen.

Wenn es aber um Redundanz geht ist das eine größere Baustelle. Dafür müsste man den IODev-mechanismus multivalue-tauglich machen, da entwickel ich hier keine Sonderlocke. Ist für mich daher erst mal out-of-scope.

Diskussionen bzw. schon fertige Layouts universell nutzbarer PCBs findest Du im MySensors Hardware Forum.

[fh168]

Ich habe gerade mal die vier Dateien ausgewechselt.

root@raspbmc:/opt/fhem# Undefined subroutine &MYSENSORS::DEVICE::onGatewayStarted called at ./FHEM/00_MYSENSORS.pm line 331.

was fehlt?

robin

[ntruchsess]

falsche Datei? Weil da isses drin...

[fh168]

jau, alte Dateien.
aber der Temperatursensor verbindet sich nicht
define mytemp MYSENSORS_DEVICE TEMP 21 0
hat sich da in der Definition irgendwas geändert?
gateway sagt folgendes:
connection
startup complete
2014-10-22 19:51:31

arduino serial log sagt folgendes:
sensor started, id 21
send: 21-21-0-0 s=255,c=0,t=17,pt=0,l=3,st=ok:1.4
send: 21-21-0-0 s=255,c=3,t=6,pt=1,l=1,st=ok:0
send: 21-21-0-0 s=255,c=3,t=11,pt=0,l=18,st=ok:Temperature Sensor
send: 21-21-0-0 s=255,c=3,t=12,pt=0,l=3,st=ok:1.0
send: 21-21-0-0 s=0,c=0,t=6,pt=0,l=3,st=ok:1.4
send: 21-21-0-0 s=0,c=1,t=0,pt=7,l=5,st=ok:23.1


Update:


Aber natürlich hat sich was geändert.

sieht jetzt bei mir so aus:


define jeelinktemp MYSENSORS /dev/ttyUSB0@115200
attr jeelinktemp room mysensors
attr jeelinktemp stateFormat connection
define temperatursensor MYSENSORS_DEVICE 21
attr temperatursensor IODev jeelinktemp
attr temperatursensor room mysensors


bei 3 18B20 Temperatursensoren kommt sogar ein Ergebnis raus.
temperature_0
25.4
2014-10-22 20:21:24
temperature_1
26.1
2014-10-22 20:21:24
temperature_2
25.9
2014-10-22 20:21:24

Nur wie kommt man an die Channel ID, wenn man nicht gerade den Sensor an den Serial-Monitor anschließen möchte?

Antwort:
Inclusion Mode beim Gateway einschalten. Damit "horcht" das Gateway für eine kurze Zeit in seinem Netzwerk herum, ob es einen neuen Sensor gibt. Dann den neuen hinzuzufügenden Sensor einmal resetten und schon nimmt das Gateway (bzw. Fhem) den Sensor in seiner Liste auf.


Anschließend wird dann sowas erzeugt:

CFGFN
DEF   
20
IODev
jeelinktemp
I_SKETCH_NAME
Soil Moisture Sensor
I_SKETCH_VERSION
1.0
NAME
MYSENSOR_20
NR
1321
STATE

TYPE
MYSENSORS_DEVICE
ack
0
radioId
20
Readings
V_TRIPPED_0
0
2014-10-22 20:35:11

Sogar mit der Sketch-Version und Sensor-Typ vom Sensor-Sketch, prima!

[ntruchsess]

das gateway verliert die connection.. wenn ich wieder auf connect draufklicke dann gehts wieder für eine gewisse zeit.

liegt vermutlich am Gateway selber. Wenn Du 'set <gateway> connect' aufrufst, wird die Serielle Schnittstelle geschlossen und wieder geöffnet. Das setzt den Arduino per Hardwarereset (DTR der Schnittstelle ist mit Reset verbunden) zurück. Gibt's was verwertbares aus dem Log? Ggf. mit verbose = 5 am Gateway noch mal laufen lassen. Ist 'requestAck' am Gateway-device aktiviert?

Gruß,

Norbert

[hexenmeister]

liegt vermutlich am Gateway selber.

Vermute ich auch. Mein GateWay läuft seit Tagen ohne Reset und Probleme. Und das obwohl es einfach wild auf dem Breadboard zusammengesteckt ist.

[ntruchsess]

Mein GateWay läuft seit Tagen ohne Reset und Probleme.

Das nehme ich jetzt mal zum Anlass die Module in's SVN einzuchecken. Ab jetzt werden die Bugs auch immer gleich dort gefixed. Patches am liebsten bitte per pull-request gegen master in meinem fhem-mirror auf github.

Gruß,

Norbert

[hexenmeister]

Habe ein Bischen die neue Version getestet....

Ohne Inclusion keine ID-Vergabe -> fix bestätigt
Wieso wird eigentlich ID 127 vergeben?
Default soll doch 20 sein (laut Doku). Ich hab kein Attribut definiert.

On/Off 'undrehen' -> funktioniert
(attr MYSENSOR_127 mapReadingType_LIGHT switch 0:on 1:off)

requeatAck funktioniert jetzt ohne Warnings-Schleife.

Warnins (z.B. beim beim Reset von RelayNode) kommen immer noch:

Code Auswählen Erweitern

2014.10.22 22:17:55.053 1: PERL WARNING: Use of uninitialized value $fields[1] in join or string at FHEM/lib/Device/MySensors/Message.pm line 33.
2014.10.22 22:17:55.053 3: stacktrace:
2014.10.22 22:17:55.054 3:     main::__ANON__                      called by FHEM/lib/Device/MySensors/Message.pm (33)
2014.10.22 22:17:55.055 3:     Device::MySensors::Message::createMsg called by ./FHEM/00_MYSENSORS.pm (373)
2014.10.22 22:17:55.055 3:     MYSENSORS::sendMessage              called by ./FHEM/10_MYSENSORS_DEVICE.pm (316)
2014.10.22 22:17:55.055 3:     MYSENSORS::DEVICE::sendClientMessage called by ./FHEM/10_MYSENSORS_DEVICE.pm (276)
2014.10.22 22:17:55.056 3:     MYSENSORS::DEVICE::onInternalMessage called by ./FHEM/00_MYSENSORS.pm (315)
2014.10.22 22:17:55.056 3:     MYSENSORS::onInternalMsg            called by ./FHEM/00_MYSENSORS.pm (261)
2014.10.22 22:17:55.057 3:     MYSENSORS::Read                     called by fhem.pl (2923)
2014.10.22 22:17:55.057 3:     main::CallFn                        called by fhem.pl (598)
2014.10.22 22:17:55.061 1: PERL WARNING: Use of uninitialized value in sprintf at FHEM/lib/Device/MySensors/Message.pm line 40.
2014.10.22 22:17:55.061 3: stacktrace:
2014.10.22 22:17:55.063 3:     main::__ANON__                      called by FHEM/lib/Device/MySensors/Message.pm (40)
2014.10.22 22:17:55.063 3:     Device::MySensors::Message::dumpMsg called by ./FHEM/00_MYSENSORS.pm (374)
2014.10.22 22:17:55.064 3:     MYSENSORS::sendMessage              called by ./FHEM/10_MYSENSORS_DEVICE.pm (316)
2014.10.22 22:17:55.064 3:     MYSENSORS::DEVICE::sendClientMessage called by ./FHEM/10_MYSENSORS_DEVICE.pm (276)
2014.10.22 22:17:55.065 3:     MYSENSORS::DEVICE::onInternalMessage called by ./FHEM/00_MYSENSORS.pm (315)
2014.10.22 22:17:55.066 3:     MYSENSORS::onInternalMsg            called by ./FHEM/00_MYSENSORS.pm (261)
2014.10.22 22:17:55.066 3:     MYSENSORS::Read                     called by fhem.pl (2923)
2014.10.22 22:17:55.067 3:     main::CallFn                        called by fhem.pl (598)
2014.10.22 22:18:00.028 3: a_automation_heartbeat: ctrl_last_RL_WZ_Light

attr <name> mapReadingType_<reading> <new reading name> [<value>:<mappedvalue>]*
configures reading user names that should be used instead of technical names

Ich fürchte, hier wird leider kein Benutzer verstehen, was die technischen Namen sind und wie sie genau heißen. Evtl. wäre besser zu ermöglichen, die sichtbaren (also eingentlich bereits gemappten) Namen anzupassen.

Irgendwie ist das noch schwer durchzublicken...
verwirrend, dass
attr MYSENSOR_127 setReading_switch_1 on,off
geht, aber nicht
attr MYSENSOR_127 setReading_switch on,off


Insgesamt läuft Modul gut.

EDIT: Bildchen

[hexenmeister]

Code Auswählen Erweitern

sub mapReading($$) {
my($hash, $type, $childId, $value) = @_;
Da fehlen noch zwei $$. Mein Perl mag es nicht so

[ntruchsess]

Danke noch mal für die Warnings, diesmal passen die Zeilennummern auch zum code

Wieso wird eigentlich ID 127 vergeben?
Default soll doch 20 sein (laut Doku). Ich hab kein Attribut definiert.

Das ist so, weil 'keys' in perl kein sortiertes Array zurückgibt (ok, könnte man einfach ändern)
20 ist nur der Vorgabewert für die kleinste mögliche ID. Das Gateway zählt nicht einfach hoch, sondern prüft, welche IDs die registrierten Nodes schon haben.

Code Auswählen Erweitern


configures reading user names that should be used instead of technical names

Ich fürchte, hier wird leider kein Benutzer verstehen, was die technischen Namen sind und wie sie genau heißen.

ich gebe zu, das verstehe ich losgelöst vom Kontext auch nicht Irgendwie ist der Satz bei copy&paste zerwürfelt worden. 'technical names' ist eh überholt. Schreib was, was auch ein DAU versteht - ich bin da etwas 'betriebsblind'

verwirrend, dass
attr MYSENSOR_127 setReading_switch_1 on,off
geht, aber nicht
attr MYSENSOR_127 setReading_switch on,off

das Reading heißt ja 'switch_1' und nicht 'switch'. Das könnte man nur besser machen, wenn man Mappings für alle bekannten Sketches hinterlegt (aber man kann sich nicht darauf verlassen, dass nicht jemand den Sketch verändert ohne den Namen zu ändern). Oder hast Du einen schlauen Vorschlag, wie man die childIds aus den Readings weglassen kann ohne Konflikte zu bekommen, wenn doch plötzlich ein Wert zu einem schon von einer anderen childId benutzen Variablentyp kommt (Und das ganze reproduzierbar und unabhängig von der Reihenfolge in der die Werte eintreffen).

Insgesamt läuft Modul gut.

danke für die Blumen

- Norbert

[ntruchsess]

hab die Warnings mal nach bestem Wissen und Gewissen behoben...


... und gleich mal mit einem EthernetGateway getestet.

Code Auswählen Erweitern


define gateway 192.168.0.6:5003


tut (fast) wie es soll. Schickt nur keine 'I_STARTUP_COMPLETE'-message - das hat aber (abgesehen vom sichtbaren STATE) aktuell keine weiteren Auswirkungen.

Gruß,

Norbert