Version 2.3.0 und Motion Sensor

Begonnen von grobby, 05 November 2018, 10:30:59

Vorheriges Thema - Nächstes Thema

grobby

Hallo Mysensors Freunde,

gestern nachdem ich einen meiner Motions Nodes umgeflasht habe und zwar auf Version 2.3.0, wunderte ich mich das "tripped" in FHEM nicht mehr aktualisiert wird. Dachte schon der Arduino hat was abbekommen. Ich sah das die Batteriewerte aber in FHEM ankommen und auch die LED bei jedem Motion das Funksignal signalisierte. Mhm komisch dachte ich, also zurück zu 2.2.0 und siehe da alles war wieder in Butter. Habe mal DEBUG eingeschalten und die Ausgabe vom Seriellen Monitor beider Versionen verglichen. Ich hänge mal die Unterschiede die mir aufgefallen sind hier an.

2.2.0
TSF:MSG:SEND,77-77-0-0,s=1,c=1,t=16,pt=0,l=1,sg=0,ft=0,st=OK:0

2.3.0
!TSF:MSG:SEND,77-77-0-0,s=1,c=1,t=16,pt=0,l=1,sg=0,ft=0,st=NACK:0

Ich denke mal es hat was mit dem ACK zu tun, was aber im Node Sketch nicht aktiviert ist und in FHEM mit "attr .... requestAck 0" aus ist.
Hat jemand einen Tip was ich falsch mache oder muss im Mysensors Modul von Fhem was geändert werden??

Grobby

Beta-User

Das ist eine nRF24-Node, oder? Da kommt das ACK von der Hardware. Die Message kommt demnach nicht an. Kann sein, dass der Treiber oder die Sendeleistung geändert wurden - schau ggf. da mal die commits auf github durch.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

grobby

Hi,

ja ein rf24 Node. Die Message kommt ja an (Batterielevel und Spannung), nur tripped fehlt. Sendleistung steht ja per Library auf HIGH. Da das Node 1m vom Gateway zum Test liegt, sollte es daran nicht liegen, ansonsten steht es immer auf MAX.

Beta-User

Versuchte mal mit einem zusätzlichen Kondensator. U.u. ist die motion-message die letzte und geht deswegen unter...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

grobby

#4
Also Hardware ging bisher ohne Probleme, seit 2.3.0 klappt es nicht, mit 2.2.0 klappt es aber. Kondensator hab ich immer schon am Nrf.
Bleibt nur ein Softwareproblem über, hab mir grad mal das Changelog durchgeschaut, aber das gibt auch keinen Anhaltspunkt.
Das Gateway läuft bei mir aber schon paar Wochen mit 2.3.0 und auch ein Temp Sensornode, der Rest noch 2.2.0.
Was bedeutet in FHEM im Mysensors Gateway "outstandingAck  1"? Hast du bei dir ACK in Betrieb?

Beta-User

ACK verwende ich teilweise. Das outstanding 1 bedeutet, dass eine message noch an irgendeine Node gehen soll.

Da fast alle meine nodes jetzt auf rs485 umgestellt sind, kann ich zu den nRF-Themen nicht mehr viel sagen. Dennoch hat sich offensichtlich was geändert, was  eben auch bedeuten kann, dass die HW anders betrieben wird und dadurch erst Schwachstellen zu Tage treten...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files