Neuigkeiten:

Am Sonntag den 8.12.2024 kann es ab ca. 8:00 Uhr zu kurzzeitigen Einschränkungen / Ausfällen bei den Diensten des FHEM Vereines kommen.
Die Server müssen mal gewartet und dabei neu gestartet werden ;)

Hauptmenü

[GELÖST] I_TIME und GATEWAY funktioniert nicht

Begonnen von SirBen, 27 Februar 2020, 15:30:20

Vorheriges Thema - Nächstes Thema

SirBen

Moin,
ich würde gerne die aktuelle Zeit an meinem Gateway von FHEM beziehen mittels requestTime().
Das mysensors Modul von FHEM ist dazu allerdings nicht in der Lage.
Es muss in der 00_MYSENSORS.pm in Zeile 375 folgendes eingefügt werden:
$type == I_TIME and do {
        if (my $client = matchClient($hash,$msg)){ MYSENSORS::DEVICE::onInternalMessage($client,$msg) }
        last;
      };

Spricht etwas dagegen? Sonst wäre es schön, wenn die Funktion eingefügt werden könnte, um beim nächsten Update nicht wieder die 00_MYSENSORS.pm zu bearbeiten.

Vielen Dank und Gruß
Ben

Beta-User

Hab's eingecheckt, auch wenn mir (noch) nicht so ganz klar ist, warum das im Fall eines GW's nicht über die "request"-Schiene abgewickelt wird...

Welche MySensors-Version hast du da auf dem GW (und auch sonst) im Einsatz?
(Falls das die allerneuste ist: Gibt es ggf. sonst noch was wichtiges, was sich geändert haben könnte?)
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

SirBen

Vielen Dank!
Soweit ich den Code verstanden habe, wird in 00_MYSENSORS bei onInternalMsg() zuerst geprüft, ob die message vom Gateway kommt. Wenn ja, dann wird geprüft, ob es sich um
$type: I_INCLUSION_MODE, I_GATEWAY_READY, I_HEARTBEAT_RESPONSE, I_VERSION, I_LOG_MESSAGE oder I_ID_REQUEST
handelt.
Dort ist halt kein I_TIME hinterlegt und die Nachricht wird ignoriert.
Wenn die message nicht von einem gateway kommt, sondern von einer bekannten Node, wird über
elsif (my $client = matchClient($hash,$msg)) {
    MYSENSORS::DEVICE::onInternalMessage($client,$msg);

das ganze an 10_MYSENSORS übergeben und verarbeitet.

Über onRequestMsg() wird keine Internal message verarbeitet. Dafür gibt es ja onInternalMsg().

Bei mir ist die überall aktuellste MYSENSORS Version (2.3.2) im Einsatz.
In dieser Version wird ACK durch Echo ersetzt. Ich weiß aber nicht in wie weit sich das auf FHEM auswirkt...

Gruß Ben

Beta-User

Thx, habe dann auch nochmal die Struktur der ganzen Funktion angesehen, dann wird das klarer. Muß bei Gelegenheit mal checken, ob es nicht sinnvoll wäre, den Code an der Stelle etwas umzustellen.
Zitat von: SirBen am 28 Februar 2020, 09:04:12
In dieser Version wird ACK durch Echo ersetzt. Ich weiß aber nicht in wie weit sich das auf FHEM auswirkt...
Ich habe eine 2.3.2-final-Node, die aber noch "isAck()" enthält. Das war mir entgegangen gewesen, dass es da Neuerungen gab, und promt macht die Probleme, wenn man mit ACK-request arbeitet... Vermutlich ist das kein Problem mehr, wenn man den Code auf der Node anpaßt, aber soweit war ich noch nicht wieder gekommen.
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

CQuadrat

#4
Problem gelöst. Ich ziehe zurück.


Hallo Zusammen,

irgendwie scheint mir die Zeitbehandlung in MySensors nicht ganz rund.

Ich hole mir im Node-Device im setup() mit requestTime() vom Gateway die aktuelle Zeit. Das sieht dann nach localtime aus (also bei mir UTC+2).

Führe ich dann im Node-Device mit
set <Node-Device> time aus, ist die Zeit dann auf einmal in UTC.

Oder habe ich einen Denkfehler?



Viele Grüße

Christoph
FHEM auf Mini-ITX-Server mit Intel Quad-Core J1900:
+ HM: HM-LAN, HM-USB, HM-MOD-UART mit div. HM-Komponenten
+ RFXtrx: Funkwetterstation Bresser mit ext. Thermometer, Regenmesser und Windmesser
+ TUL (KNX-Anbindung), MQTT, SONOS (div. Gimmicks), OneWire, Hue