Autor Thema: [patch] 10_MYSENSORS_DEVICE.pm - Fix für falsche Bootloader-Abfrage beim Update  (Gelesen 882 mal)

Offline pldemon

  • New Member
  • *
  • Beiträge: 11
Hallo,

danke für das Modul! Top! Die Anfrage des eingesetzten Bootloaders beim Reboot-Kommando wird bei MYSBootloader aber so nicht auslösen, da der Hash (zumindest bei mir) leer ist. Bei Optiboot greift die zweite Kondition, weshalb das Konstrukt funktioniert.

Habe das Modul für meine Bedürfnisse folgendermaßen angepasst:

--- 10_MYSENSORS_DEVICE.orig    2020-11-28 11:54:56.261163746 +0100
+++ 10_MYSENSORS_DEVICE.pm      2020-11-28 11:58:06.755827232 +0100
@@ -282,14 +282,18 @@
       
       if ($command eq "reboot") {
         my $blVersion = ReadingsVal($name, "BL_VERSION", "");
-        defined($hash->{OTA_BL_Type}) or $blVersion eq "3.0"
-          ? return sendClientMessage($hash,
+        my $blType = AttrVal($name, "OTA_BL_Type", "");
+
+        return sendClientMessage($hash,
                                      childId => 255,
                                      cmd => C_INTERNAL,
                                      ack => 0,
                                      subType => I_REBOOT
-                                     )
-            : return;
+                                     )
+           if (($blType eq "MYSBootloader") ||
+               ($blType eq "Optiboot" and $blVersion eq "3.0"));
+
+       return;
       }
       
       if ($command eq "clear") {

Gruß,
demon
« Letzte Änderung: 28 November 2020, 12:06:36 von pldemon »

Offline Beta-User

  • Moderator
  • Hero Member
  • ***
  • Beiträge: 13634
  • "Developer"?!? Meistens doch eher "User"
Danke für die Rückmeldung und den Hinweis!

Hab's leicht verändert eingecheckt, wäre nett, wenn du die aktuelle Version aus dem svn holen könntest und kurz checken, ob alles so funktioniert wie gewünscht :) . (oder eben ab morgen früh via update; ich habe derzeit keine Test-Nodes, insbesondere keine mit allen möglichen Bootloadern, es müßte aber eigentlich funktionieren...)
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | BT@OpenMQTTGateway
svn:MySensors, WeekdayTimer, RandomTimer, Twilight,  AttrTemplate => {mqtt2, mysensors, zwave}

Offline pldemon

  • New Member
  • *
  • Beiträge: 11
Hi,

so wird es nicht funktionieren. Die Anfrage benötigt Klammern  ;)
https://svn.fhem.de/trac/changeset/23254/trunk/fhem/FHEM/10_MYSENSORS_DEVICE.pm

So wird's...
(AttrVal($name, "OTA_BL_Type", 0) or ReadingsVal($name, "BL_VERSION", 0))

Hab im Übrigen gestern auch FOTA getestet und es funktionierte tadellos. Saubere Arbeit!

Gruß,
demon

Offline pldemon

  • New Member
  • *
  • Beiträge: 11
Mit dem aktuellen Stand aus dem SVN kommt folgende Fehlermeldung beim reboot:

reboot not defined: no mapping for reading reboot

Gruß,
demon
« Letzte Änderung: 29 November 2020, 15:12:51 von pldemon »

Offline Beta-User

  • Moderator
  • Hero Member
  • ***
  • Beiträge: 13634
  • "Developer"?!? Meistens doch eher "User"
Thx für's testen, update mit der Klammer ist im svn...

(Der OTA-Basiscode stammt btw. - wie der überwiegende Teil des gesamten Codes - von anderen...)
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | BT@OpenMQTTGateway
svn:MySensors, WeekdayTimer, RandomTimer, Twilight,  AttrTemplate => {mqtt2, mysensors, zwave}

 

decade-submarginal