[gefixed] Heutiges CUL_HM update defekt

[Christoph Morrison]

Weiterentwicklungen sollen und müssen auch sein. Vielleicht sollte man aber mal das Update-Konzept überprüfen. Bei vielen Entwicklungen gibt es z.B. die Möglichkeit, beim Update zwischen ,,stable" und ,,development" wählen zu können.
Beispiel: bei Homematic würde ich immer auf stable zurückgreifen wollen, bei MQtt(2) aktuell auf development.

Ceterum censeo: Umstellung auf ein Plugin-Modell, bei dem die einzelnen Module nicht per default dabei sind, sondern über einen Plugin Manager nachinstalliert werden können. Jeder User könnte - wie beim Debian-Modell - stable, oldstable, testing, etc. wählen, was auch immer besser zu seinem Setup passt. Der aktuelle update-Mechanismus ist viel zu grob um eine stabile Plattform ermöglichen zu können.

Just my 0.02€

[Florian_GT]

Ceterum censeo: Umstellung auf ein Plugin-Modell, bei dem die einzelnen Module nicht per default dabei sind, sondern über einen Plugin Manager nachinstalliert werden können. Jeder User könnte - wie beim Debian-Modell - stable, oldstable, testing, etc. wählen, was auch immer besser zu seinem Setup passt. Der aktuelle update-Mechanismus ist viel zu grob um eine stabile Plattform ermöglichen zu können.

Just my 0.02€

Ein Update-Manager finde sehr gut. Ich würde aber nicht nur Update Channel sondern auch gerne Versionen sehen. Jedes Module eine eigene Version. Wobei zur Vereinfachung Version auch ein Git Hash sein kann. Dann könnte es auch einen Roleback knopf geben, wo man direkt zur vorherigen Version springen kann. Außerdem könnte man die Änderungen aus der GIT History holen, als Dokumentation der Änderungen. Und eine Auswahl zwischen auto-update und manual-update.

[oldscout]

Hallo,
ich bin auch dafür, dass nicht alle Module im FHEM Ordner sein sollten, alle werden immer  mit aktualisiert, obwohl sie nicht im Einsatz sind.
An der Stelle auch eine Idee: Lassen sich in der FHEM Reference nicht die Module mit "Alphabet-Reitern" sortieren?
Eine unendliche Menge sind da mittlerweile verfügbar, und dadurch ist die Übersichtlichkeit nicht mehr so toll.
Danke.

[MadMax-FHEM]

ich bin auch dafür, dass nicht alle Module im FHEM Ordner sein sollten, alle werden immer  mit aktualisiert, obwohl sie nicht im Einsatz sind.

Und dann beschließt du irgendwann ein neues Modul zum ersten Mal benutzen zu wollen und lädst dann (bzw. fhem) eine total veraltete nicht kompatible Version des Moduls...

Das ist bestimmt besser...

Aber langsam sollte (wenn überhaupt) wohl ein eigener Thread bzgl. Update-Strategie, -Problematik, -... eröffnet werden...

Gruß, Joachim

[martinp876]

Hi,

1) also einenUpdate-Manager müsst ihr im allgemeinen Forum beantragen. CUL_HM und die anderen Module machen das nicht. In diesem Forum wird es also nicht fruchten.
1a) Jeden Modul hat eine eigene Version - schon jetzt. Kann man sehen und aus SVN zurückholen.
1b) einzelne Module vom User zu maintainen halte ich für ambitioniert. Module haben Abhängigkeiten. CUL_HM ist weit unten in der Architektur, hat also wenige, bspw zu HMConfig. HMInfo hat zu CUL_HM und zu HMConfig. HMtemplate natürlich zu HMInfo. HMLan hat auch ein paar Abhängigkeiten. Wegen mir könnt ihr euer Glück versuchen. Typisch verwendet man hier allerdings eher Build labels..... Ich will das bei mir nicht einzeln maintainen.
2) der aktuelle Stand ist identisch zu dem vor dem 1.6.. Das zeigt der SVN vergleich. Wenn man also diesen zusammen mit den configs zu diesem Zeitpunkt  einspielt müsste alles beim Alten sein.
3) HMConfig habe ich heute erneuert. Das darf keine Schwierigkeiten machen, sind interne Angelegenheiten.
4) @curt: danke für die Info. Leider kann ich es nicht nachvollziehen. Ich haben eine Config nach "alter Schule" (ohne ".mId") und mache reboots. Dann sind alle Kommando da. Ich suche die Fehler nicht beim Nutzer, ich suche den Fehler/das Szenario.
4a) was waren deine Fehlerleldungen? In der Vorrede sehe ich ausschliesslich "attr .mId unbekannt". Nach einem Reboot damals verstehe ich das nicht. Jetzt (heute) ist es klar - wir hatten einen Roleback.
5) @ Octek0815: verstehe ich auch nicht. Das system war am laufen, du hattest schon einen reboot - korrekt? nun kein Update mehr aber ein neuer Reboot - Jetzt hast du Probleme. Auch nur das fehlende .mId oder etwas anderes?
6) @awel: wie waren die Sensoren vor den Update definiert? Das Attr "Model" fehlt, CUL_HM weiss also nicht, um was es sich handelt. Wenn deine Config nicht überschrieben ist, oder du noch eine alte hast, sollte es nachvollziehbar sein. Wenn du einmal config drückst würden CUL_HM auch wieder alles eintragen.
7) @oldscout: auf welcher Version warst du? Hat du ein List eines der Rollos?

[Leinad]

Ich habe vorhin ein update gemacht, und muss nun leider feststellen, dass es auch mein System irgendwie zerschossen hat.

Meine Tür und Fensterkontakt werden nicht mehr korrekt erkannt. Dadurch kann ich auch kein peerChan mehr absetzen.

Ist es Sinn jetzt für jeden Senor model und subtype von Hand einzustellen? Ist das Problem damit gelöst?

//EDIT: Ein getConfig scheint das Problem zu beheben. (Siehe Punkt 6 im vorigen Post)
Bekomme nun allerdings häufig  RESPONSE TIMEOUT:RegisterRead - ob das damit zsammen hängt weiss ich nicht.

[Sidey]

Hi, bin mir nicht sicher ob folgender Fehler bereit bekannt ist.

Ich habe virtuelle Temperatur Sensoren die sich nicht mehr aktualisieren lassen, da der Set Befehl dazu nicht mehr bekannt ist.
Ein getConfig hat da nicht geholfen:

Code Auswählen Erweitern


Internals:
   CFGFN      /opt/fhem/cfg/fhem_2_umgebungsensoren.cfg
   DEF        100201
   IODev      HMUART
   NAME       wz.vTmp1
   NOTIFYDEV  global
   NR         116
   NTFY_ORDER 50-wz.vTmp1
   STATE      RESPONSE TIMEOUT:RegisterRead
   TYPE       CUL_HM
   channel_01 wz.vTmp1_Sensor1
   channel_02 wz.vTmp1_Btn2
   channel_03 wz.vTmp1_Btn3
   channel_04 wz.vTmp1_Btn4
   protCmdDel 3
   protResnd  9 last_at:2019-01-13 18:07:05
   protResndFail 3 last_at:2019-01-13 18:07:09
   protSnd    3 last_at:2019-01-13 18:06:51
   protState  CMDs_done_Errors:1
   READINGS:
     2019-01-13 18:07:09   state           RESPONSE TIMEOUT:RegisterRead
     RegL_00.:
       VAL       
   helper:
     HM_CMDNR   250
     cSnd       01272F5B10020100040000000000,01272F5B10020100040000000000
     mId       
     expert:
       def        1
       det        0
       raw        1
       tpl        0
     io:
       newChn     +100201,00,02,00
       prefIO     
       rxt        0
       vccu       VCCU
       p:
         100201
         00
         02
         00
     mRssi:
       mNo       
       io:
         HMLAN1:
         HMUART:
     prt:
       bErr       0
       sProc      0
     q:
       qReqConf   
       qReqStat   
     role:
       dev        1
     rssi:
     shadowReg:
     tmpl:
Attributes:
   IODev      HMLAN1
   IOgrp      VCCU
   autoReadReg 4_reqStatus
   expert     2_raw
   model      VIRTUAL
   verbose    5
   webCmd     virtual


Code Auswählen Erweitern


Internals:
   CFGFN      /opt/fhem/cfg/fhem_2_umgebungsensoren.cfg
   DEF        10020101
   NAME       wz.vTmp1_Sensor1
   NOTIFYDEV  global
   NR         117
   NTFY_ORDER 50-wz.vTmp1_Sensor1
   STATE      set_virtTemp 21.8
   TYPE       CUL_HM
   chanNo     01
   device     wz.vTmp1
   peerList   wz.Heizung_Weather,
   READINGS:
     2018-12-23 00:21:56   humidity        0
     2019-01-13 17:28:39   peerList        wz.Heizung_Weather,
     2019-01-08 22:34:47   state           set_virtTemp 21.8
     2019-01-08 22:34:47   temperature     21.8
   helper:
     expert:
       def        1
       det        0
       raw        1
       tpl        0
     role:
       chn        1
     shadowReg:
     tmpl:
Attributes:
   model      VIRTUAL
   peerIDs    38989B01,
   room       Wohnzimmer


[frank]

//EDIT: Ein getConfig scheint das Problem zu beheben. (Siehe Punkt 6 im vorigen Post)

falsch interpretiert.
du sollst das knöpfchen am device entsprechend drücken ("config drückst"), um eine anlernmessage auszulösen, denn nur dort steht die model id drin. kein "set getconfig".

[Leinad]

  danke! funzt

Ich fasse zusammen:
Nach dem Update hatte ich Fehlermeldungen bzgl attr .mid

Nach einem Reboot des Systems waren die Fehlermeldungen weg, -> Die "typen" bzw. "model" der  einzelnen Geräte wurden aber nicht erkannt.

Ein drücken des config-Taster am Gerät behebt das Problem.

[LuckyDay]

@Sidey

schau nach Model und subType attr
bei deinem virtuellen Sensor

https://wiki.fhem.de/wiki/HM-CC-RT-DN_Funk-Heizk%C3%B6rperthermostat

[curt]

@martinp876

4) @curt: danke für die Info. Leider kann ich es nicht nachvollziehen. Ich haben eine Config nach "alter Schule" (ohne ".mId") und mache reboots. Dann sind alle Kommando da.

4a) was waren deine Fehlerleldungen? In der Vorrede sehe ich ausschliesslich "attr .mId unbekannt". Nach einem Reboot damals verstehe ich das nicht. Jetzt (heute) ist es klar - wir hatten einen Roleback.

Ich beschreibe nochmals so genau wie möglich:

Ich habe HM-SEC-*

Wohl am 09.01. am sehr frühen Morgen
* update check
* update
* shutdown restart
(kein Save in meiner Erinnerung im Spiel!

Ergebnis:
* Im Browser Klick auf "Home". In MOTD (message of the day) werden ALLE HM-SEC-* wie folgt aufgelistet:
** "HM_xxxxxx: unknown attribute .mId. Type 'attr HM_xxxxxx ?'

Mein Gedanke: Oh, unschön. Kann man nichts machen, wird sich aufklären. Mal abwarten und beobachten.

Einen Tag später bemerke ich (den folgenden Fehler bemerkte ich erst dann), dass in meiner FTUI-Oberfläche mein Fester des Arbeitszimmers nicht korrekt angezeigt wird. Am Abend dann genauer angesehen:

* Im FHEM-Raum habe ich eine ReadingsGroup über alle Tür/Fensteröffner - die war komplett leer. Huch? Logfile, was weißt Du? "trigger_cnt: xx" und "alive" kommt noch, sonst aber nichts. Boah, was das denn?

* JEDE HM-SEC-* hatte das attr "model" so gesetzt -> model   HASH(0x48b14f8) [Werte unterschiedlich]

* HM-SEC-SCo zusätzlich im STATE "RESPONSE TIMEOUT:RegisterRead" / HM-SEC-SC-2 keine weiteren Besonderheiten.

Ok, wozu habe ich Vollsicherungen?
FHEM shutdown. Die beiden genannten *.pm mit Stand vom 23.12. zurückgeschrieben. Als debian-root: reboot.

* Zustand unverändert.
* hm update.
* Zustand unverändert.
* Forum sagt "nun wieder das update fahren!". Ok:
** update
** shutdown restart
(kein Save in meiner Erinnerung im Spiel!

Prüfen.
* Zustand unverändert.

Anfrage hier im Thread. @MadMax-FHEM hilft mir auf das Pferd:
* set VCCU hmPairForSec 60
* zum Sensor rennen, Knopf drücken
* zurückrennen: set getconfig (dieses Sensors)
* zum Sensor rennen, Knopf drücken
* GoTo1 (für alle Sensoren)
* freuen, alles wieder gut. @MadMax-FHEM danke sagen.

Hoffe geholfen zu haben. Nachfragen - gern.

P.S: @all
Updatemanagement, meine Sicht in gebotener Kürze:
1) Das ist ein Hobbyprojekt, das muss man alles auch leisten können.
2) Bei vielen Modulen WILL man ja gerade die neuesten Updates!
3) Einzig sinnvoller Vorschlag scheint mir: Sofortiges Zurückziehen des fehlerhaften Updates, Fehlerthread aufmachen, Beta-Test-Thread aufmachen.
1Ct.

[martinp876]

@ Sidney: Das Attr "model" steht bei dir auf "VIRTUAL" - was in der neuen Konfiguraiton relevant wird. Das ist also noch etwas aus einem Zwischen-update. Irgend etwas hast du nicht sauber zurück geführt.

@Curt: vielleicht war es zu früh. Die Korrekte Version wäre 18184
@Curt b): wenn das Device eine Config message sendet (kann man durch die Config-Taste am Device auslösen) wird CUL_HM das verarbeiten. Pairen ist nicht erforderlich! also keine Aktion (hmPairForSec....)

@all:
- die neue Version HMConfig ist online - morgen im update, heute im Anhang. Ist gefahrlos, da keine reconfig durchgeführt wird.
- eine neue Version von CL_HM ist im Anhang, nicht online.
=> ich empfehle einen manuellen Update zum Testen
   1) beide Dateien downloaden / einspielen
   2) shutdown restart ausführen
   3) im Fehlerfall die beiden alten Dateien wieder einspielen und ein shutdown restart. Da kein save stattgefunden hat ist wieder alles beim Alten
Meine Tests
  - VCCU  erfolgreich
  - Virtuelle Devices und Channels funktionieren
  - Rollos funktionieren
  - Heizung funktioniert
  - Grafik funktioniert
  - ich habe im gesamten Verlauf NIE ein device neu gepeert/gepairt oder register umgeschrieben

[yersinia]

[...]
(kein Save in meiner Erinnerung im Spiel!)
[...]
(kein Save in meiner Erinnerung im Spiel!)

Wird das save ggf automatisch beim Update (und vor dem shutdown restart) durchgeführt?
Zumindest bei einem weiteren shutdown restart wird das ja dann zwangsweise gespeichert, oder?

Anbei ein Log-Auszug vom Update heute (Markierung hab ich hinzugefügt):

Code Auswählen Erweitern

2019.01.13 09:28:11 1: fhem
2019.01.13 09:28:11 1: UPD ./CHANGED
2019.01.13 09:28:11 1: UPD ./MAINTAINER.txt
2019.01.13 09:28:11 1: UPD FHEM/10_MQTT_GENERIC_BRIDGE.pm
2019.01.13 09:28:11 1: UPD FHEM/39_alexa.pm
2019.01.13 09:28:11 1: UPD FHEM/59_Weather.pm
2019.01.13 09:28:11 1: UPD FHEM/92_FileLog.pm
2019.01.13 09:28:11 1: UPD FHEM/DarkSkyAPI.pm
2019.01.13 09:28:11 1: UPD FHEM/OpenWeatherMapAPI.pm
2019.01.13 09:28:12 1: saving fhem.cfg     <=================
2019.01.13 09:28:12 1: saving ./log/fhem.save <=================
2019.01.13 09:28:12 1:
2019.01.13 09:28:12 1: New entries in the CHANGED file:
2019.01.13 09:28:12 1:   - feature: 39_alexa.pm: added support autostart of alexa-fhem
2019.01.13 09:28:12 1:                           added support for pubic FHEM Connector skill
2019.01.13 09:28:12 1:   - change:  59_Weather completely reworked

[curt]

@Curt: vielleicht war es zu früh. Die Korrekte Version wäre 18184
@Curt b): wenn das Device eine Config message sendet (kann man durch die Config-Taste am Device auslösen) wird CUL_HM das verarbeiten. Pairen ist nicht erforderlich! also keine Aktion (hmPairForSec....)

Das mag alles so sein. In meiner Verunsicherung habe ich es halt so gemacht. Schau mal: Ich habe mir das alles eigentlich nur wegen "habe ich alle Fenster geschlossen?" angeschafft (alles andere kam mit Freude später). Also ist mir wichtig, dass Türen und Fenster auch wirklich gemeldet werden.

Die neuerliche umfangreiche Auflistung habe ich gemacht, weil Du mich darum gebeten hast. Nur aus diesem Grund. (Falls Du oder irgendwer nun einen Vorwurf herausliest - da ist KEIN Vorwurf. Mir ist sehr wohl klar, was FHEM ist - und ich bin da auch sehr dankbar.)

P.S - kam dazwischen:
@yersinia Meine Anmerkungen bezogen sich auf mein Vorgehen. Hier konkret: Händische, von mir gewollt ausgelöste Handlungen. Vielleicht insofern missverständlich formuliert.

[krannich]

Hi martinp876,

Update: Läuft nach einem kompletten Neustart wieder.
ich habe noch das Problem, dass der Fenstertürgriff (HM-SEC-RHS) nicht funktioniert.

Besteht immer noch:
Zudem bekomme ich noch folgende Meldung im Log (unabhängig vom anderen Problem):
PERL WARNING: Use of uninitialized value in hash element at /opt/fhem//FHEM/10_CUL_HM.pm line 7677.

Vielleicht hilft es ja.

Viele Grüße
Dennis