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ü

FOTA-Problem MySensors

Begonnen von eiten, 10 Juni 2020, 14:47:52

Vorheriges Thema - Nächstes Thema

eiten

Hallo Zusammen,

wenn ich einen Sensor flashen will, dann kommt im Log immer:
2020.06.10 14:43:50 3: MYSENSORS: ignoring stream-msg from unknown radioId 10, childId 255 for ST_FIRMWARE_REQUEST
2020.06.10 14:43:53 3: MYSENSORS: ignoring stream-msg from unknown radioId 10, childId 255 for ST_FIRMWARE_REQUEST
2020.06.10 14:43:56 3: MYSENSORS: ignoring stream-msg from unknown radioId 10, childId 255 for ST_FIRMWARE_CONFIG_REQUEST
2020.06.10 14:43:59 3: MYSENSORS: ignoring stream-msg from unknown radioId 10, childId 255 for ST_FIRMWARE_CONFIG_REQUEST
2020.06.10 14:43:59 3: MYSENSORS: ignoring stream-msg from unknown radioId 10, childId 255 for ST_FIRMWARE_REQUEST
2020.06.10 14:44:02 3: MYSENSORS: ignoring stream-msg from unknown radioId 10, childId 255 for ST_FIRMWARE_REQUEST
2020.06.10 14:44:05 3: MYSENSORS: ignoring stream-msg from unknown radioId 10, childId 255 for ST_FIRMWARE_REQUEST
2020.06.10 14:44:08 3: MYSENSORS: ignoring stream-msg from unknown radioId 10, childId 255 for ST_FIRMWARE_REQUEST


Die radioid ist aber einem Device zugeordnet:


Internals:
   DEF        10
   FUUID      5ee0d1e2-f33f-9f51-d4f8-e2a61c9f1bffa909
   IODev      MySensorsGW
   NAME       MY_PoolTempTest
   NR         159
   OTA_requested 1
   STATE      updating
   TYPE       MYSENSORS_DEVICE
   ack        0
   radioId    10
   repeater   0
   version    2.3.2
   FW_DATA:
     12
     148
     [...]
     255
     255
     255
   READINGS:
     2020-06-10 14:45:53   BL_VERSION      1.3
     2020-06-10 14:45:53   FW_BLOCKS       80
     2020-06-10 14:45:53   FW_CRC          26163
     2020-06-10 14:31:20   FW_TYPE         10
     2020-06-10 14:35:45   SKETCH_NAME     MockMySensors
     2020-06-10 14:35:45   SKETCH_VERSION  v0.5
     2020-06-10 14:35:49   armed1          on
     2020-06-10 14:35:49   batteryPercent  41
     2020-06-10 14:35:44   parentId        0
     2020-06-10 14:41:18   state           updating
     2020-06-10 14:35:49   tripped1        on
   gets:
   readingMappings:
     1:
       15:
         name       armed1
       16:
         name       tripped1
   retainedMessagesForRadioId:
   setcommands:
   sets:
     clear      noArg
     flash      noArg
     fwType     
     reboot     noArg
     time       noArg
Attributes:
   IODev      MySensorsGW
   OTA_BL_Type MYSBootloader
   mapReading_armed1 1 armed
   mapReading_tripped1 1 tripped
   mode       node


Irgendwelche Ideen?

Danke und Gruss, Edi

Beta-User

Zitat von: eiten am 10 Juni 2020, 14:47:52
Irgendwelche Ideen?
Jein...

U.A. auch an der Stelle ist der Code vor kurzem umgebaut worden. Ich gehe mal davon aus, dass wir über die aktuelle Modulfassung reden?

Eigentlich meine ich, die fragliche Zeile (https://svn.fhem.de/trac/browser/trunk/fhem/FHEM/00_MYSENSORS.pm#L748) würde nur zum Tragen kommen, wenn für eine Message keine passende IO/Client-ID-Kombination gefunden wird.

Ergo würde ich vermuten, es gibt ein zweites IO, das die Anfragen des Sensors auch liest, das Update selbst läuft aber durch?

Wo die Message herkommt, könntest du mit der folgenden Änderung rausbekommen:
Log3($hash->{NAME},3,"MYSENSORS: ignoring stream-msg from unknown radioId $msg->{radioId}, childId $msg->{childId} for ".datastreamTypeToStr($msg->{subType})." IO: $hash->{NAME}");
(oder es ist mir ein Fehler unterlaufen)
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

eiten

Hallo Beta-User,

Danke Dir! Deine Änderung hat's gebracht: ich hatte noch ein 2. GW definiert... vor Jahren... und vergessen  :P! Jetzt sind die Fehler weg. Mal schauen, ob das update jetzt durchläuft!

Gruss, Edi



Beta-User

Ähm, wenn das update bisher nicht durchgelaufen ist, würde ich mal tippen, dass du irgendeinen anderen Kanal als Channel 76 für den regulären Verkehr nutzt?
Dann mußt du das 2., "vergessene" GW als update-IO angeben, sonst wird das nicht funktionieren mit dem update; der läuft nämlich bei dem 1.3-OTA-Bootloader über Channel 76 (es sei denn, du hättest den selbst gebaut und das geändert).

Ich bau den erweiterten Hinweis aber trotzdem noch in den Code ein, da stolpert früher oder später bestimmt wieder mal jemand drüber...



Noch was anderes:
"definiert" heißt, dass es nicht angeschlossen war? Oder lief der Verkehr unbemerkt die ganze Zeit darüber?
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