HM updates

Begonnen von martinp876, 16 November 2013, 15:18:11

Vorheriges Thema - Nächstes Thema

MadMax-FHEM

Hallo,

habe es eben noch mal nachvollzogen (leider komme ich aktuell nicht mehr zurück, leider bei diesem Testsystem kein BackupBeforeUpdate...):

nach einem Update (Fhem 5.6 -> 5.7 also Stand heute) fehlen bei den HM-Komponenten einige Readings, u.a. R-lowBatLimitRT (daher habe ich es gemerkt, weil meine Batteriestandsanzeige nicht mehr gestimmt hat).

Hier das Listing einer Beispielkomponente meines Testsystems:


Internals:
   DEF        453732
   IODev      nanoCUL868
   LASTInputDev nanoCUL868
   MSGCNT     130
   NAME       HM_453732
   NR         134
   NTFY_ORDER 50-HM_453732
   STATE      CMDs_done
   TYPE       CUL_HM
   channel_01 HM_453732_Weather
   channel_02 HM_453732_Climate
   channel_03 HM_453732_WindowRec
   channel_06 HM_453732_remote
   channel_07 HM_453732_SwitchTr
   lastMsg    No:02 - t:00 s:453732 d:AFFE02 1300AD4E4551303132323533365803FFFF
   nanoCUL868_MSGCNT 130
   nanoCUL868_RAWMSG A1A028400453732AFFE021300AD4E4551303132323533365803FFFF::-46:nanoCUL868
   nanoCUL868_RSSI -46
   nanoCUL868_TIME 2016-03-13 21:07:49
   protCondBurst on
   protLastRcv 2016-03-13 21:07:49
   protSnd    124 last_at:2016-03-13 21:07:47
   protState  CMDs_done
   rssi_at_nanoCUL868 avg:-44.36 min:-46 max:-42.5 lst:-46 cnt:130
   Readings:
     2016-03-13 21:07:49   Activity        alive
     2016-03-13 21:07:32   CommandAccepted yes
     2016-03-13 21:07:49   D-firmware      1.3
     2016-03-13 21:07:49   D-serialNr      NEQ0122536
     2016-03-13 21:07:32   PairedTo        0xAFFE02
     2016-03-13 21:07:32   R-burstRx       on
     2016-03-13 21:07:32   R-cyclicInfoMsg on
     2016-03-13 21:07:32   R-cyclicInfoMsgDis 0
     2016-03-13 21:07:32   R-pairCentral   0xAFFE02
     2016-03-13 21:07:32   RegL_00.          01:01 02:01 09:01 0A:AF 0B:FE 0C:02 0F:00 11:00  12:16 16:01 18:00 19:00 1A:00 00:00
     2016-03-13 21:07:47   state           CMDs_done
     Regl_07.:
       VAL
   Helper:
     HM_CMDNR   2
     cSnd       01AFFE024537320703,01AFFE0245373207040000000001
     mId        00AD
     rxType     6
     Expert:
       def        1
       det        0
       raw        1
       tpl        0
     Io:
       newChn     +453732,00,00,00
       nextSend   1457899669.8897
       prefIO
       rxt        0
       vccu
       p:
         453732
         00
         00
         00
     Mrssi:
       mNo        02
       Io:
         nanoCUL868 -44
     Prt:
       awake      0
       bErr       0
       brstWu     0
       sProc      0
       Rspwait:
     Q:
       qReqConf
       qReqStat
     Role:
       dev        1
     Rssi:
       At_nanocul868:
         avg        -44.3692307692308
         cnt        130
         lst        -46
         max        -42.5
         min        -46
     Shregw:
       07         02
     Shadowreg:
Attributes:
   IODev      nanoCUL868
   actCycle   000:10
   actStatus  alive
   autoReadReg 4_reqStatus
   expert     2_full
   firmware   1.3
   model      HM-TC-IT-WM-W-EU
   msgRepeat  1
   room       CUL_HM
   serialNr   NEQ0122536
   subType    thermostat
   webCmd     getConfig:clear msgEvents



Hatte das gleiche Problem beim System meiner Freundin.
Habe hier und dort bereits die Readings gelöscht und getConfig, hat aber nichts geholfen.

Das System meiner Freundin habe ich wieder zurück gerüstet (Backup eingespielt) und promt war das Reading R-lowBatLimitRT wieder da...

Stimmt da bei mir etwas nicht, oder hat sich da ein Fehler eingeschlichen??

Vielen Dank, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

Amenophis86

Kann es sein, dass die Readings in einem Channel waren? Viele sind im Laufe der letzten Zeit von einem Channel ins Hauptdevice verlagert worden. Schau mal da nach.
Aktuell dabei unser neues Haus mit KNX am einrichten. Im nächsten Schritt dann KNX mit FHEM verbinden. Allein zwei Dinge sind dabei selten: Zeit und Geld...

CoolTux

#32
Hallo Joachim

Dein expert Attribut ist nicht mehr aktuell, schau mal was Du da jetzt zur Auswahl hast.


Grüße
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

MadMax-FHEM

Hi,

ok vielen Dank schon mal.
Ich schau mal nach ob sich die Daten jetzt woanders befinden...
...und auch wegen dem attr...

Gruß, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

ph1959de

Also zumindest R-lowBatLimitRT befindet sich noch am HM-CC-RT-DN Device selbst, wird aber erst sichtbar, wenn attr expert 1_allReg gesetzt ist.

Peter
Aktives Mitglied des FHEM e.V. | Moderator im Forenbereich "Wiki"

FunkOdyssey

Ich lese hier mit und war auch verwundert über die neuen Möglichkeiten des Attributs "expert".
Beim Sichten ist mir aufgefallen, dass die Auswahl in FHEM von der Dokumentation in der CommandRef abweicht. Die englische Dokumentation ist dabei auch wieder ein wenig anders.

MadMax-FHEM

Hi,

DANKE!

attr expert 1_allReg war die Lösung!!
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

Neuhier

Habe die betreffende Datei heruntergeladen, nach /opt/fhem kopiert und fwUpdate gestartet.

Es kommt: file corrupt. length:2759 expected:2760

Auch mehrmaliges Downloaden bringt den gleichen Fehler.

Also die Datei selber ist OK.

Benenne ich die zu *.eq3 um, statt *.tgz, ist das Ergebnis gleich.

FunkOdyssey

Und wenn man die Datei vorher entpackt? 😄

sku

https://wiki.ubuntuusers.de/tar/#Extrahieren

*.tgz ist das gleiche wie *.tar.gz, daher mit
tar -xzf archiv.tgz
einfach entpacken

Neuhier

Danke, wird sofort getestet.
Bin davon ausgegangen, daß es nur als Archiv verwendet werden kann.

Frank_Huber

#41
Morgen zusammen,

ich schaffe es nicht meine HM-ES-PMSw1-Pl  auf 2.5 hochzuziehen. Stand heute hat sie 1.6.
als CUL dient ein miniCUL v2 mit FW: V 1.24.02 a-culfw Build: private build (unknown) miniCUL (F-Band: 868MHz)

Update-Zeilen im Log:
Zitat2017.09.22 11:06:00 2: CUL_HM fwUpdate started for HM_5BAB0A
2017.09.22 11:06:00 3: CUL_HM set HM_5BAB0A fwUpdate /opt/fhem/FHEM/firmware/HM-ES-PMSw1-Pl-DN-R1_update_V2_5_0009_150217.eq3 30
2017.09.22 11:06:01 2: CUL_HM fwUpdate HM_5BAB0A entered mode. IO-speed: fast
2017.09.22 11:06:06 1: PERL WARNING: Use of uninitialized value $mNo in sprintf at ./FHEM/10_CUL_HM.pm line 7022.
2017.09.22 11:06:31 2: CUL_HM fwUpdate HM_5BAB0A end. IO-speed: normal

was läuft falsch? unterliege ich einem Layer 8 Problem?


EDIT:

Ja, Layer 8 Problem...
Habe mir jetzt das FW HTTPMOD eingerichtet und da drüber die FW erneut heruntergeladen.
Siehe da, ich hatte eine falsche FW...

falsch:  HM-ES-PMSw1-Pl-DN-R1_update_V2_5_0009_150217.eq3
richtig: HM-ES-PMSw1-Pl_update_V2_5_0009_150217.eq3

Zitat2017.09.22 11:25:10 2: CUL_HM fwUpdate started for HM_5BAB0A
2017.09.22 11:25:10 3: CUL_HM set HM_5BAB0A fwUpdate /opt/fhem/FHEM/firmware/HM-ES-PMSw1-Pl_update_V2_5_0009_150217.eq3
2017.09.22 11:25:11 2: CUL_HM fwUpdate HM_5BAB0A entered mode. IO-speed: fast
2017.09.22 11:27:58 2: CUL_HM fwUpdate HM_5BAB0A end. IO-speed: normal
2017.09.22 11:27:58 2: CUL_HM fwUpdate completed

Danke für eure Aufmerksamkeit. ;)

Neuhier

Das mit dem

HM-ES-PMSw1-Pl-DN-R1_update_V2_5_0009_150217.tzg

hat mich auch gewaltig irritiert.

Dann in den Attributes nachgesehen, dort ist ohne DN-R1.