Vorarbeiten: Update auf MySensors 2.0-API

Begonnen von Beta-User, 22 Juni 2018, 20:28:35

Vorheriges Thema - Nächstes Thema

Beta-User

Flag im sketch muss gesetzt sein an der Node. Dann get ausführen.
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

Ranseyer

Danke. Das hatte ich übersehen: #define MY_SIGNAL_REPORT_ENABLED

Dann per Webfrontend "get xy RSSI" und mal aktualisieren: Ändert nichts. RSSI=1

Also habe ich auch das Gateway neu geflasht mit "#define MY_SIGNAL_REPORT_ENABLED". Keine Änderung.

Am Gateway sehe ich beim "get xy RSSI" entsprechende Aktivitäten. Am Sensor-Node wird dazu nichts auf der Debug-Konsole ausgegeben.

Denke ich muss erst mal in die Sonne raus ... 8) (Wenn das laufen würde könnte ich mal die 433MHzr LoRa Nodes testen die auf dem Tisch liegen)
FHEM mit FTUI. Homematic-Funk für Thermostate und Licht. MySensors als Basis für eigene HW.
Zentrale ist der MAPLE-CUL mit RFM69+HModUART-AddOn.
Doku zu meinen Projekten: Github/Ranseyer. Platinen falls verfügbar gerne auf Anfrage.
Support: gerne wenn ich Zeit+Lust habe im Forum. Nicht per PN!

Beta-User

Moin,

eine "Kleinigkeit" scheine ich nicht klar genug zum Ausdruck gebracht zu haben: FHEM muss wissen, wann die Node erreichbar ist. Schläft die Node überwiegend, kommt die Info von smartSleep statt sleep, dann bleibt der Transceiver vor dem Einschlafen erst noch kurz wach (default: 500ul => sinnvollerweise erhöhen für nicht 1MHz-Arduinos).

Mein Testcode, ergänzt um MY_SMART_SLEEP_WAIT_DURATION_MS:

// Enable debug prints to serial monitor
#define MY_DEBUG
#define MY_NODE_ID 20

// Enable and select radio type attached
//#define MY_RADIO_NRF24
//#define MY_RADIO_NRF5_ESB
//#define MY_RADIO_RFM95

//Special Options for testing new FHEM module
#define MY_SPECIAL_DEBUG
//#define
#define MY_SIGNAL_REPORT_ENABLED //most likely only needed for nRF-Type nodes to get a pseudo-value - https://forum.mysensors.org/topic/9073/new-2-2-0-signal-report-function
#define MY_SMART_SLEEP_WAIT_DURATION_MS 500

#define MY_RADIO_RFM69
#define MY_IS_RFM69HW // Lokale Vorschriften beachten !
#define MY_RFM69_FREQUENCY RFM69_868MHZ
#define MY_RFM69_NEW_DRIVER


// Define a lower baud rate for Arduino's running on 8 MHz (Arduino Pro Mini 3.3V & SenseBender)
#if F_CPU == 8000000L
#define MY_BAUD_RATE 38400
#endif



#include <MySensors.h>

uint32_t SLEEP_TIME = 30000; // Sleep time between reports (in milliseconds)
#define DIGITAL_INPUT_SENSOR 3   // The digital input you attached your motion sensor.  (Only 2 and 3 generates interrupt!)
#define CHILD_ID 1   // Id of the sensor child

// Initialize motion message
MyMessage msg(CHILD_ID, V_TRIPPED);

void setup()
{
  pinMode(DIGITAL_INPUT_SENSOR, INPUT);      // sets the motion sensor digital pin as input
}

void presentation()
{
  // Send the sketch version information to the gateway and Controller
  sendSketchInfo("Motion Sensor", "1.0");

  // Register all sensors to gw (they will be created as child devices)
  present(CHILD_ID, S_MOTION,"Test 0.1 ä");
}

void loop()
{
  // Read digital motion value
  bool tripped = digitalRead(DIGITAL_INPUT_SENSOR) == HIGH;

//  Serial.println(tripped);
//  send(msg.set(tripped?"1":"0"));  // Send tripped value to gw
  //wait(1000);
  // Sleep until interrupt comes in on motion sensor. Send update every two minute.
  smartSleep(digitalPinToInterrupt(DIGITAL_INPUT_SENSOR), CHANGE, SLEEP_TIME);
}


Hoffe, das ist jetzt klarer. Man kannt den Verlauf/Status prüfen (und die Anzahl der zurückgehaltenen Messages usw.), indem man den Browser refresht, diese internen Vorgänge sind nicht-triggernd.

Gruß, Beta-User
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

Ranseyer

Danke, damit konnte ich das Problem "lösen". (Aktuell mit RFM69)

Ursache waren zwei Probleme. Ich denke es geht nur mit smartSleep. Das kommt zwar im Text vor, aber mir war nicht klar dass das sein muss.
Und dann klappt es bei mir trotzdem nur "gelegentlich". Bei MotionSensor muss ich den Finger auf der Sensor-Pin legen um das nötige Chaos herzustellen damit der Sensor quasi andauern funkt.

Denke das kennst Du selber schon.

Im Sketch steht bei mir gerade:
Zitatpresent(CHILD_ID, S_MOTION,"Test 0.1 ä");

Daraus wird dann in den Readings:
Zitattripped_Test_0.1_
FHEM mit FTUI. Homematic-Funk für Thermostate und Licht. MySensors als Basis für eigene HW.
Zentrale ist der MAPLE-CUL mit RFM69+HModUART-AddOn.
Doku zu meinen Projekten: Github/Ranseyer. Platinen falls verfügbar gerne auf Anfrage.
Support: gerne wenn ich Zeit+Lust habe im Forum. Nicht per PN!

Ranseyer

Das nächste wäre LoRa 433 gewesen, aber FHEM ist abgeschmiert.

Das ist mit dieser kleinen Testinstanz vorher noch nie passiert. Das ist das Ende vom Logfile:
2018.07.21 09:14:08 4: MYSENSORS/RAW: /0;
2018.07.21 09:14:08 4: MYSENSORS/RAW: 0;/255;3;0;9;3600003 TSM:READY:NWD REQ
0;255;3
2018.07.21 09:14:08 4: MYSENSORS Read: Rx: fr=000 ci=255 c=003(C_INTERNAL    ) st=009(I_LOG_MESSAGE   ) ack=0 '3600003 TSM:READY:NWD REQ'

2018.07.21 09:14:08 5: MYSENSORS gateway mySensGwRFM69: 3600003 TSM:READY:NWD REQ
2018.07.21 09:14:08 4: MYSENSORS/RAW: 0;255;3/;0;9;3600017 TSF:MSG:SEND,0-0-255-255,s=255,c=3,t=20,pt=0,
2018.07.21 09:14:08 4: MYSENSORS/RAW: 0;255;3;0;9;3600017 TSF:MSG:SEND,0-0-255-255,s=255,c=3,t=20,pt=0,/l=0,sg=0,ft=0,st=OK:
0;255;3;0;9;3600039 TSF:SAN:OK

2018.07.21 09:14:08 4: MYSENSORS Read: Rx: fr=000 ci=255 c=003(C_INTERNAL    ) st=009(I_LOG_MESSAGE   ) ack=0 '3600017 TSF:MSG:SEND,0-0-255-255,s=255,c=3,t=20,pt=0,l=0,sg=0,ft=0,st=O
K:'

2018.07.21 09:14:08 5: MYSENSORS gateway mySensGwRFM69: 3600017 TSF:MSG:SEND,0-0-255-255,s=255,c=3,t=20,pt=0,l=0,sg=0,ft=0,st=OK:
2018.07.21 09:14:08 4: MYSENSORS Read: Rx: fr=000 ci=255 c=003(C_INTERNAL    ) st=009(I_LOG_MESSAGE   ) ack=0 '3600039 TSF:SAN:OK'

2018.07.21 09:14:08 5: MYSENSORS gateway mySensGwRFM69: 3600039 TSF:SAN:OK
2018.07.21 09:14:36 5: MYSENSORS outstanding ack, re-send: Rx: fr=111 ci=255 c=003(C_INTERNAL    ) st=006(I_CONFIG        ) ack=1 'M'

2018.07.21 09:14:36 5: SW: 3131313b3235353b333b313b363b4d0a
2018.07.21 09:14:37 4: MYSENSORS/RAW: /0;255;3;0;9;3629017 !TSF
2018.07.21 09:14:37 4: MYSENSORS/RAW: 0;255;3;0;9;3629017 !TSF/:MSG:SEND,0-0-111-111,s=255,c=3,t=6,pt=0,l=1,sg=0,ft=0,st=NACK:M

2018.07.21 09:14:37 4: MYSENSORS Read: Rx: fr=000 ci=255 c=003(C_INTERNAL    ) st=009(I_LOG_MESSAGE   ) ack=0 '3629017 !TSF:MSG:SEND,0-0-111-111,s=255,c=3,t=6,pt=0,l=1,sg=0,ft=0,st=N
ACK:M'

2018.07.21 09:14:37 5: MYSENSORS gateway mySensGwRFM69: 3629017 !TSF:MSG:SEND,0-0-111-111,s=255,c=3,t=6,pt=0,l=1,sg=0,ft=0,st=NACK:M
Not an ARRAY reference at ./FHEM/10_MYSENSORS_DEVICE.pm line 928.
FHEM mit FTUI. Homematic-Funk für Thermostate und Licht. MySensors als Basis für eigene HW.
Zentrale ist der MAPLE-CUL mit RFM69+HModUART-AddOn.
Doku zu meinen Projekten: Github/Ranseyer. Platinen falls verfügbar gerne auf Anfrage.
Support: gerne wenn ich Zeit+Lust habe im Forum. Nicht per PN!

Ranseyer

LoRa 433 lauft auch und gibt  auf die kurze Entfernung ein RSSI von -9 und nach zwei Wänden von -43
=>plausibel !

Was ich immer noch nicht so recht verstanden habe: Wenn ich keinen Zugriff auf den Node habe muss ich mich also vor FHEM setzen und warten bis der Node "awake" ist, und dann get RSSI absetzen.
Bei einem Default von 500ms ist das doch kaum machbar. Oder ? (Ich musste da mal z.B. 10000 eintragen um auch zuverlässig Erfolg zu haben...)

FHEM mit FTUI. Homematic-Funk für Thermostate und Licht. MySensors als Basis für eigene HW.
Zentrale ist der MAPLE-CUL mit RFM69+HModUART-AddOn.
Doku zu meinen Projekten: Github/Ranseyer. Platinen falls verfügbar gerne auf Anfrage.
Support: gerne wenn ich Zeit+Lust habe im Forum. Nicht per PN!

dirkcx

ich habe noch zwei "Probleme" entdeckt:

a) ist der FW_TYPE einmal gesetzt, kann man den Node nicht mit einem anderen Sketch mit anderem FW_TYPE flashen. Ich hatte einen Node auf FW_TYPE 81 für Testzwecke und die 81 dann wieder entfernt aus der config-Datei. Dann wollte ich den Node auf einen Sketch vom Typ 80 flashen, aber fhem hat das Reading immer wieder auf 81 zurück gesetzt und der alte Sketch blieb.

b) wenn ich einen Node mittels eines anderen Tools (z.B. MYSController) per FOTA flashe, dann stürzt fhem immer ab. Der Node war in fhem angemeldet.
Kommt selten vor, aber manchmal muss ich halt noch ohne fhem arbeiten, wenn FOTA per fhem nicht klappt  ;)
Server: Gigabyte GB-BACE3160 | Ubuntu 20.04 LTS Server | aktuelles FHEM | CULUSB (busware) FS20/FHT/... | MySensors: seriell / esp8266 | ZigBee (Zigbee CC2531 / zigbee2mqtt) | homebridge / homebridge-config-ui

Beta-User

Danke für die Rückmeldungen, das klingt ja erst mal nach Arbeit :( .

Ohne das im Detail auf die Schnelle analysieren zu können:

- Das mit FW_TYPE muß ich mir ansehen. Wenn ich das richtig verstanden habe, wird zwar das set ausgeführt, aber dann trotzdem immer die erste gemachte Vorgabe abgearbeitet. Richtig?

- Was den Absturz bei Verwendung eines weiteren Controllers angeht: Steht dazu was im Log? (ich hoffe mal, dass es auch Zeile 928 ist...) Sonst evtl. mal bitte Stacktrace einschalten und den Absturz provozieren.

- Man muß mit irgendwelchen Befehlen nicht warten, bis die Node auf "awake" geht. Die Message wird in ein Array geschrieben und dann wieder daraus gelesen, sobald die Node ein "ich bin jetzt wach" sendet (genau wie alle Ack-Messages nochmal gesendet werden, die nicht zugestellt worden sind). Die Abfrage der Größe des Arrays steht in Zeile 928, die für den Absturz bei Ranseyer verantwortlich war. Allerdings ist mir nicht recht klar, wie das zustande kommt, weil FHEM sich für das Array nur dann interessiert, wenn die Node schläft und versucht wird, was zu senden. Die einzige Ausnahme von diesem Prinzip sind update-bezogene messages für nRF-Nodes - die gehen direkt an das IO (Chanel76, wenn vorhanden, sonst das normale).

=>Könnt ihr die Zeile mal in "eval ($hash->{retainedMessages}=scalar(@$messages));" ändern, dann sollte sich FHEM wenigstens nicht mehr weghängen?
- Die Umwandlung der Sonderzeichen bei den Kommentaren ist Absicht - was du da gefunden hast, war ein nicht beseitigter Testcode, ob das funktioniert ;) . Feststellung: Scheinbar klappt das nicht nur bei mir, wenigstens was 8) ...
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

dirkcx

#68
@Beta-User
R_RSSI_from_Parent zeigt nun übrigens -37 an, ich bringe den Node mal in ein anderes Zimmer...

ZitatWenn ich das richtig verstanden habe, wird zwar das set ausgeführt, aber dann trotzdem immer die erste gemachte Vorgabe abgearbeitet. Richtig?
korrekt

ZitatSteht dazu was im Log?
nein, mein Loglevel ist "1", sorry. Der Hänger war zwischen 11:14 und 11:35 Uhr, dazwischen ist nichts im log. Ich werde das mal reproduzieren, aber vermutlich heute nicht mehr - Pool ruft  ;)

2018.07.21 11:14:23 5: MYSENSOR_5: timeoutMySTimer called (timeoutAwake)
2018.07.21 11:35:57 5: MYSENSOR_5: refreshInternalMySTimer called (Alive)


Zeile 928 ist bei mir eine Leerzeile, ich hab wohl nicht die aktuellste Version der 10_MYSENSORS_DEVICE.pm. Ich bringe mein System auf den aktuellen Stand.

Update: habe die Zeile 928 nun angepasst.

Reicht eigentlich ein reload 10_MYSENSORS_DEVICE.pm um Änderungen wirksam zu machen oder muss ich fhem neu starten?
Server: Gigabyte GB-BACE3160 | Ubuntu 20.04 LTS Server | aktuelles FHEM | CULUSB (busware) FS20/FHT/... | MySensors: seriell / esp8266 | ZigBee (Zigbee CC2531 / zigbee2mqtt) | homebridge / homebridge-config-ui

dirkcx

@Beta-User

woher ziehst Du die Werte für
XDBG_CPU_FREQUENCY  80
XDBG_CPU_VOLTAGE    2344
XDBG_FREE_MEMORY    1280


Könnte man da auch die CPU Temperatur auslesen als XDBG_CPU_TEMPERATURE?
Server: Gigabyte GB-BACE3160 | Ubuntu 20.04 LTS Server | aktuelles FHEM | CULUSB (busware) FS20/FHT/... | MySensors: seriell / esp8266 | ZigBee (Zigbee CC2531 / zigbee2mqtt) | homebridge / homebridge-config-ui

Ranseyer

ZitatMan muß mit irgendwelchen Befehlen nicht warten, bis die Node auf "awake" geht. Die Message wird in ein Array geschrieben und dann wieder daraus gelesen,

Wow, das ist cool und hätte ich nicht erwartet. Wenn ich also 10* "get RSSI" absetze dann macht er das also wohl brav der Reihe nach.
Ich hab da schon ordentlich Befehle abgesetzt weil es ein ungutes Gefühl ist, wenn die TX/RX LEDs nicht blinken wenn man das Zeug über ein FTDI Modul speist...
Da wäre ggf. besser mit nem SDR oder so mitzuhören statt auf die LEDs zu schauen...  :'(

Danke nochmals für den Einsatz!
FHEM mit FTUI. Homematic-Funk für Thermostate und Licht. MySensors als Basis für eigene HW.
Zentrale ist der MAPLE-CUL mit RFM69+HModUART-AddOn.
Doku zu meinen Projekten: Github/Ranseyer. Platinen falls verfügbar gerne auf Anfrage.
Support: gerne wenn ich Zeit+Lust habe im Forum. Nicht per PN!

Beta-User

Hinter den DEBUG-Werten steckt https://www.mysensors.org/apidocs-beta/group__SerialDebugGrpPub.html#ga261ca40adab009c13aaf354c9064d958 - ganz am Ende. Temperatur geht daher also nicht. Dürfte bei den Arduinos auch kein größeres Thema sein, da wird ja immer dasselbe gemacht.

Das mit der FW_TYPE wird vermutlich etwas dauern.

Den Verbose-Level hast du ja schon hochgedreht, wenn ich das richtig interpretiere. Dann hilft wohl nur ein stacktrace (wenn es das mit Zeile 928 nicht war).

Ein Reload sollte in der Regel reichen.
Nein, wenn du 10* get RSSI eingibst, wird nur 1* am Ende tatsächlich gesendet; der Code sollte so intelligent sein, dass neue Anweisungen an dasselbe Child die alten überschreiben (wenn du also ein "aus" für ein Licht im der Queue hast, dann "ein" sendest, bleibt am Ende nur das "ein" im Array ;) ). Geklaut von der Ack-Logik ::) .

Ob gesendet wurde, sieht man an der Größe des Arrays (=> Zeile 928...), die im Internal "retainedMessages" steht ;) .
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

dirkcx

Mit der Codeänderung stürzt fhem nicht mehr ab, wenn ein Node extern per FOTA eine neue Software bekommt.
Server: Gigabyte GB-BACE3160 | Ubuntu 20.04 LTS Server | aktuelles FHEM | CULUSB (busware) FS20/FHT/... | MySensors: seriell / esp8266 | ZigBee (Zigbee CC2531 / zigbee2mqtt) | homebridge / homebridge-config-ui

Beta-User

Zitat von: dirkcx am 21 Juli 2018, 14:11:47
R_RSSI_from_Parent zeigt nun übrigens -37 an, ich bringe den Node mal in ein anderes Zimmer...
Ähm, das ist doch nRF24, oder? Das wäre ja eine angenehme Überraschung :) :) :) !

Zitat von: dirkcx am 21 Juli 2018, 17:37:13
Mit der Codeänderung stürzt fhem nicht mehr ab, wenn ein Node extern per FOTA eine neue Software bekommt.
Danke für die Info, dann baue ich das bei nächster Gelegenheit ein. Schadet in jedem Fall nicht, auch wenn mir völlig unklar ist, wie es dazu kommt, dass dieses Array an der Stelle des Codes nicht exisitiert... Aber vielleicht komme ich ja noch irgendwann dahinter oder jemand erklärt es mir.
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

Ranseyer

Zitat von: Beta-User am 21 Juli 2018, 18:39:15
Ähm, das ist doch nRF24


Nee RFM96W , also die LoRa 433MHz Stamps von Hope.
NRF* habe ich keine mehr.
FHEM mit FTUI. Homematic-Funk für Thermostate und Licht. MySensors als Basis für eigene HW.
Zentrale ist der MAPLE-CUL mit RFM69+HModUART-AddOn.
Doku zu meinen Projekten: Github/Ranseyer. Platinen falls verfügbar gerne auf Anfrage.
Support: gerne wenn ich Zeit+Lust habe im Forum. Nicht per PN!