[CUL_HM] patches Oktober 2021 - die Zweite

Begonnen von Beta-User, 15 Oktober 2021, 23:56:29

Vorheriges Thema - Nächstes Thema

Beta-User

Bitte mal ins log schauen, siehe info von benni im nachbarthread
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

MadMax-FHEM

Zitat von: Beta-User am 30 Oktober 2021, 19:21:21
Bitte mal ins log schauen, siehe info von benni im nachbarthread

Meinst du den hier: https://forum.fhem.de/index.php/topic,123744.msg1183120.html#msg1183120

Also ich hab nichts auffälliges im Log, weder Testsystem noch HAuptsystem.

Auf dem Testsystem sogar mal shutdown restart -> alles gut!

Nutze aber kein AES...

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)

Benni


Rampler

#108
Bin mir jetzt nicht sicher, ob das hier interessiert...
Jedenfalls habe ich heute früh einen update gemacht (via SVN), bis jetzt alles gut..
SVN und hier sollten momentan gleich sein oder ?
3 HMUART (2 via ESP8266), 1 DUOFERN, 9 ESP8266, RPI2 (Bullseye), ZWAVE, HM-Classic, und hoch zufrieden ...
Danke an alle, die was dazu beigetragen haben !!

BroPi

Habe hier als stiller User alle Betaversionen immer gleich eingespielt und viele Verbesserungen gespürt ohne groß was zu melden. Vielen Dank für die tolle Arbeit.
Es ist ein super stabiler Stand erreicht worden. Die Renameproblematik hat mich sehr gestört. Alles ist jetzt bestens.
Bei mir laufen hier 2 Systeme parallel. Mein Nachbar in der 2-ten Haushälfte hat eine Menge an HM-Gerätschaften. Und im Funk sehen wir uns gegenseitig.
Neuanmeldungen gingen oft schief, da trotz ausgeschalteter Autocreate-Funktion, Geräte angelegt wurden und dazwischen feuerten.

Nun folgender Test (10_CUL_HM.pm:?/2021-10-29 UNSTABLE):

Mein System: autocreate disabled
Nachbarsystem: autocreate enabled

Nachbarsystem: set vccu hmPairForSec 120 -> Anlernen durch Tastendruck

-> Device wurde im Nachbarsystem angelegt, auf dem meinem System ist nichts passiert (so soll es sein) es wurde aber ein unknown_ bei der vccu eingetragen.

Da kann ich jetzt gut mit leben. Übrigens: ein Fehler ist noch seit 2 Tagen im Logfile aufgetaucht:

2021.10.31 10:34:05 3: CUL_HM set kl_Zimmer_Mode_Btn press short all Burst 0 0.25
[b]2021.10.31 10:34:07 1: PERL WARNING: Use of uninitialized value $ctrlMode in right bitshift (>>) at ./FHEM/10_CUL_HM.pm line 2507.[/b]
2021.10.31 10:34:13 3: CUL_HM set Gaube_Mode_Btn press short all Burst 0 0.25
2021.10.31 10:35:00 3: CUL_HM set Anbau_Mode_Btn press short all Burst 0 0.25
2021.10.31 11:00:16 3: CUL_HM set VCCU update noArg
2021.10.31 11:00:16 3: CUL_HM set VCCU update noArg


Auch das doppelte Auftreten der VCCU update ist immer noch da, stört aber nicht weiter.

Benni

Zitat von: Rampler am 31 Oktober 2021, 17:06:59
SVN und hier sollten momentan gleich sein oder ?

Würde mich auch interessieren!
Ist das was gestern noch von martinp876 und mgernoth eingecheckt wurde der Stand, der auch hier anhängt?

Aktuell habe ich nämlich bei mir genau das alles erst mal vom update ausgeschlossen.

gb#

Beta-User

Hallo zusemmen,
Zitat von: Rampler am 31 Oktober 2021, 17:06:59
Bin mir jetzt nicht sicher, ob das hier interessiert...
Jedenfalls habe ich heute früh einen update gemacht (via SVN), bis jetzt alles gut..
SVN und hier sollten momentan gleich sein oder ?
Ganz gleich nicht, meine Kommentare sind z.B. ja zum überwiegenden Teil dafür da festzuhalten, wo die Quelle zur Lösung zu finden ist bzw. das Problem zu finden.

Im ersten Post war zu HMUARTLGW schon gestern was zu lesen, und zum Rest seit eben.

HMLAN scheint ein Problem mit dem Einchecken zu haben, Details hatte Martin nicht mitgeteilt. Ich hatte erst die commandref im Verdacht, vermute jetzt aber eher einen neueren pre-commit-hook, z.B.  "my $foo= 'Bäh' if $baz". Mehr weiß ich im Moment nicht, also falls jemand Ideen hat oder die betreffende Stelle identifizieren kann: gerne!

Was CUL_HM betrifft, gibt es zum einen gewisse Teile (rund um autocreate), die Martin nicht übernommen hat, aber die wesentlichen Teile schon. Das im Detail durchzugehen, wird etwas dauern, bei autocreate scheine ich das nicht gut erklärt zu haben...

Nach der Meldung von @benni wg. des Loggings gehe ich auch davon aus, dass wir da so oder so noch mal nacharbeiten sollten. Aktueller Ansatz dazu wäre, ein Internal hochzählen zu lassen und bei Nichtvohandensein des Internals auch eine (erweiterte) verbose 0-Meldung ins Log zu schreiben. So sollte das einmalig passieren, und man kann am Zähler erkennen, wie gravierend das Problem ist?

Weiter war da noch was mir den AES-Keys, das noch unrund war.

Was heißt das nun:
- die svn-Fassung sollte für die meisten User ok sein, wer HMLAN im Einsatz hat, sollte bis zum Einchecken eines Updates die gepatchte von hier verwenden.
- Wer noch nicht die gepatchte Fassung hatte oder bisher nicht ins Log geschaut hatte, sollte so oder so  (von der svn-Vorversion oder einer früheren patch-Version kommend nach dem update) ins Log schauen, ob das wegen eines Konfigurationsproblems "explodiert" und die Ursache beheben
- dringliche Aktionen bzgl. update vs. Version von hier sind m.E. nicht erforderlich.
- Es wird vermutlich nochmal eine Runde geben zu den o.g. Problemen. Von daher wäre ich dankbar, wenn es wieder ein paar Tester gäbe, oder:

Falls jemand Muße hat:
- Mein nächster Ausgangspunkt betr. CUL_HM wäre wieder eine "verglichene" Version auf aktuellem svn-Stand.
- Über TYPE=autocreate kann man streiten, ich meine aber, die Prüfung auf aktiviertes Pairing sei sinnvoll. Vielleicht sollte man Martin diese vereinfachte Variante vorschlagen? (Falls ichwas übersehe, darf mich an der Stelle auch jemand wissendes bremsen).
- Es dürfte nicht so schwierig sein, die o.g. Punkte noch abzuarbeiten.
-- Speziell @benni: ggf. könntest du einen Vorschlag zu dem Counter-Thema liefern? (kann auch in die letzte patch-Fassung eingebaut sein)
-- das mit den AES-keys ist ein Sonderthema bei der Attr-Routine bzw. der NotifyFn, aber vermutlich auch nicht übermäßig komplex. Je schneller wir einen getesteten Lösungsvorschlag haben, desto schneller wird es im svn landen - also "Freiwillige vor" (auch hier ist es m.E. prinzipiell egal, welche Basis).

Hoffe, der Stand ist jetzt klarer.
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

frank

#112
ZitatHMLAN scheint ein Problem mit dem Einchecken zu haben, Details hatte Martin nicht mitgeteilt.
die lösung hatte rudi umgehend gepostet
https://forum.fhem.de/index.php/topic,110125.msg1183519.html#msg1183519
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

frank

#113
ZitatNach der Meldung von @benni wg. des Loggings gehe ich auch davon aus, dass wir da so oder so noch mal nacharbeiten sollten. Aktueller Ansatz dazu wäre, ein Internal hochzählen zu lassen und bei Nichtvohandensein des Internals auch eine (erweiterte) verbose 0-Meldung ins Log zu schreiben. So sollte das einmalig passieren, und man kann am Zähler erkennen, wie gravierend das Problem ist?
warum so ein aufwand mit dem zähler? das ist kontraproduktiv und falsch, finde ich.
user handeln in der regel sofort, wenn das blütenweisse log beschmuddelt wird.  ;)
also: viele einträge => viel aufmerksamkeit => schnelles handeln.

benni hatte ja vermutlich schon immer einen konfigurationsfehler, der bisher nicht aufgefallen war.
wenn bennis erinnerung richtig ist und cul_hm deviceabhängig sowohl mit als auch ohne vccu arbeitet, hat cul_hm hier auch falsch gehandelt. die vccu darf hier kein io aussuchen, da nur attr IODev gesetzt war.
vermutlich war in diesen devices helper/io/vccu falsch gesetzt.

in die meldung gehört der devicename, damit man weiss welches device betroffen ist, um die konfiguration zu checken.


edit: martin erlaubt explizit gemischtes io handling
ZitatBeispiel Obsolet
Die Attribute "IOgrp" und "IOdev" schliessen sich aus. Der User kann einstellen, das die vccu sich um das IO kümmert ODER er definiert sein eigenes ODER er überlässt alles dem fhem-kernel.
https://forum.fhem.de/index.php/topic,122107.0.html
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

Benni

Zitat von: frank am 01 November 2021, 11:08:04
in die meldung gehört der devicename, damit man weiss welches device betroffen ist, um die konfiguration zu checken.

Genau das hatte ich eigentlich auch gemeint mit dem "besseren Logging."

Mir ging es gar nicht um eine Reduzierung der Messages, sondern (generell) um den Informationsgehalt der Meldungen, also woher kommt der Fehler, bzw. welches device ist davon betroffen, das ist in so einem Fall hilfreich und Zielführend!

Gehäufte (gleich lautende?) Messages zu sammeln und zu reduzieren um das Log nicht zu überfüllen wäre wahrscheinlich wesentlich zentraler aufzuhängen, Da müsste man ggf. erweiterte Log-Funktionen schaffen. Glaube nicht, dass Rudi oder sonst wer da so spontan Lust dazu hat. :)

Ich denke auch: Viele Meldungen => größerer Handlungsdruck => schnellere Problemlösung!

gb#



Benni

Zitat von: frank am 01 November 2021, 11:08:04
edit: martin erlaubt explizit gemischtes io handlinghttps://forum.fhem.de/index.php/topic,122107.0.html

Ob das aber wirklich sinnvoll ist?
Ich denke ein IO, das über eine vccu verwaltet wird, sollte dem User nicht mehr als IO für die explizite Zuweisung per Att IODev zur Verfügung stehen. Dazu wäre dann ja das prefered-IO in IOgrp zu verwenden.

Ein IO, das nicht mehr unter der Verwaltung einer vccu steht, natürlich schon!
Das wäre dann übrigens bei mir der Fall gewesen: Das IO hat in der FHEM-Installation ja noch existert (dummy=1 / physikalisch nicht mehr vorhanden) und war dem Device per Attr IODev zugewiesen. Also hätte hier gar keine IO-Zuweisung stattfinden müssen.
Auch dann hätte ich wahrscheinlich die Fehlkonfiguration schnell gefunden denn das entsprechende Device hätte einfach nicht mehr funktioniert.

Allerdings hätte dann schon früher, als das IO noch unter Verwaltung der vccu stand, die Fehlkonfiguration in vccu auffallen können. Hätte sogar stillschweigend korrigiert werden können, indem IODev gelöscht und IOgrp entsprechend mit vccu und prefered IO gesetzt worden wäre.

gb#

Gisbert

Hallo Beta-User,

ich hatte den HMLAN vor längerer Zeit außer Betrieb genommen, da sich ein disconnect ans andere reihte.
Nachdem ich ein Update beim 00_HMLAN.pm (?), genau weiß ich es nicht mehr, gemacht hatte, lief es sehr gut.

In den letzten Tagen, insbesondere mit der aktuellen Version, kommen wieder häufiger disconnects.

Viele​ Grüße​ Gisbert​
Aktuelles FHEM | PROXMOX | Fujitsu Futro S740 | Debian 12 | UniFi | Homematic, VCCU, HMUART | ESP8266 | ATtiny85 | Wasser-, Stromzähler | Wlan-Kamera | SIGNALduino, Flamingo Rauchmelder FA21/22RF | RHASSPY

Beta-User

#117
Zitat von: Gisbert am 02 November 2021, 07:53:16
Nachdem ich ein Update beim 00_HMLAN.pm (?), genau weiß ich es nicht mehr, gemacht hatte, lief es sehr gut.

In den letzten Tagen, insbesondere mit der aktuellen Version, kommen wieder häufiger disconnects.
Bin etwas ratlos, welche Version du denn wann jetzt genau im Einsatz hattest. Die aktuelle svn-Version ist ja schon recht alt, und eventuell hattest du den in der im ersten Thread auch eingeflossenen patch angewendet?




Wie dem auch sei, ich bin jetzt mal über die letzten Fassungen von HMLAN und CUL_HM drüber und hätte wieder mal Testversionen im Angebot - bislang von meiner Seite nur grob angetestet.

Änderungen HMLAN:- use DevIo; (wg. pre-commit hooks?)
- ansonsten bisherige patch-Fassung, aber ohne Instanz-Hash-:Clients:, also insbesondere (hoffentlich) weiter verbessertes reconnect/reboot-Verhalten.

Änderungen CUL_HM:
- :Clients:-Erkennung so umgestellt, dass man es in HMLAN nicht braucht (vereinfachte Fassung per einfacher alternativer Abfrage auf TYPE=HMLAN). Die Aktualisierung von HM_LAN ist damit nicht mehr verpflichtend, sondern nur noch empfolen;
- Counter für die IO-Geschichte eingebaut (mAn. ist die aktualisierte Logik schneller als die alte! Es wird nur einmal ein (um den Device-Namen erweiterter) Log-Eintrag erzeugt). In dem Zusammenhang: Die alte Logik war eigentlich nur erst mal ein erster Versuch, um irgendwelchen Missmatches überhaupt auf die Spur zu kommen, und von daher auch noch nicht bis ins letzte durchdacht und ausgereift...
- gg. der bisherigen patch-Fassung etwas vereinfachte Logik für das automatisierte Anlegen von Devices (nur noch hmPair aktiv?-Abfrage).
- Manche der von Benni in https://forum.fhem.de/index.php/topic,123744.msg1183485.html#msg1183485 geschilderten warnings müßten beseitigt sein. Allerdings ist mir nicht ganz klar, wie die überhaupt entstanden sind... Da scheint auch sonst noch irgendwas kaputt gewesen zu sein.
- "proposed"-Ermittlung aus Reading ist entsprechend Martins Wünschen draußen, kann sein, dass damit auch ein Teil der Mismatches in der Zuweisung entfällt (oder was dazukommt ::) ). Auch von daher macht das mit dem Counter m.E. mehr Sinn.

Für die key-Zuweisung bei AES, wenn man neue IO's in die VCCU-IOList aufnimmt (?) habe ich derzeit noch keine Idee.

Werde es bei Gelegenheit auch selbst wieder im Echtsystem testen, aber die bisherige Geschwindigkeit kann ich nicht mehr leisten. Nach dem Selbsttest gibt es dann vermutlich einen "November"-Patches-Thread ;) .

Über die Änderungen an den anderen Dateien habe ich weiter nur überschlägig geschaut.
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

mumpitzstuff

#118
Ich habe keine Ahnung ob ich hier richtig bin, aber nachdem ich heute ein "update all" angestoßen habe, sind alle meine Feuermelder (HM-SEC-SD) im state: unreachable. Hat jemand eine Idee woran das liegen könnte?

Internals:
   DEF        23457F
   FUUID      5c4b8852-f33f-55cb-ee36-49cbe6bf5a10d383
   FVERSION   10_CUL_HM.pm:0.251580/2021-10-30
   IODev      MapleWifi868
   NAME       SMOKE_SCHLAFZIMMER
   NR         31
   NTFY_ORDER 48-SMOKE_SCHLAFZIMMER
   STATE      unreachable
   TESTNR     1
   TYPE       CUL_HM
   chanNo     01
   disableNotifyFn 1
   peerList   self01
   protCmdDel 1
   protResnd  1 last_at:2021-11-02 19:26:19
   protResndFail 1 last_at:2021-11-02 19:26:24
   protSnd    1 last_at:2021-11-02 19:26:14
   protSndB   2 last_at:2021-11-02 19:26:19
   protState  CMDs_done_Errors:1
   sdTeam     sdLead
   READINGS:
     2021-11-02 19:35:52   Activity        alive
     2021-09-01 16:12:28   D-firmware      1.0
     2021-09-01 16:12:28   D-serialNr      KEQ0709128
     2021-11-02 19:26:14   IODev           MapleWifi868
     2021-11-02 11:01:52   PairedTo        0x26E92F
     2021-09-01 16:33:43   R-pairCentral   0x26E92F
     2021-11-02 11:01:52   RegL_00.        00:00 02:01 0A:26 0B:E9 0C:2F
     2021-11-02 11:01:48   battery         ok
     2021-11-02 11:02:53   cfgState        ok
     2021-11-02 19:26:24   commState       CMDs_done_Errors:1
     2021-10-28 08:32:45   eventNo         0C
     2021-11-02 11:01:48   level           0
     2021-11-02 19:25:52   peerList        self01
     2021-11-02 11:01:47   powerOn         2021-11-02 11:01:47
     2021-10-28 08:32:32   recentAlarm     vccu
     2021-11-02 11:01:48   recentStateType info
     2021-10-28 08:32:45   smoke_detect    none
     2021-11-02 19:26:34   state           unreachable
     2021-10-28 08:30:40   teamCall        from vccu:2
     2020-07-18 21:10:39   trigLast        SMOKE_SCHLAFZIMMER:short
     2020-07-18 21:10:39   trig_SMOKE_SCHLAFZIMMER Short_4
     2021-10-28 08:30:40   trigger         Short_2
     2021-10-28 08:32:46   trigger_cnt     12
   helper:
     HM_CMDNR   170
     cSnd       ,0126E92F23457F010E
     fkt        sdLead1
     mId        0042
     peerFriend peerSD
     peerIDsState complete
     peerOpt    p:smokeDetector
     regLst     0
     rxType     2
     cmds:
       TmplKey    self01:no:1635877552.36656
       TmplTs     1635877552.36656
       cmdKey     1:1:0:sdLead1:SMOKE_SCHLAFZIMMER:0042:01:self01
       cmdLst:
         alarmOff   noArg
         alarmOn    noArg
         assignHmKey noArg
         clear      [({msgErrors}|msgEvents|rssi|attack|trigger|register|oldRegs|readings|all)]
         deviceRename -newName-
         fwUpdate   -filename- [-bootTime-]
         getConfig  noArg
         getDevInfo noArg
         getRegRaw  (List0|List1|List2|List3|List4|List5|List6|List7) [-peerChn-]
         peerBulk   -peer1,peer2,...- [({set}|unset)]
         peerChan   -btnNumber- -actChn- [({single})] [({set}|unset)] [({actor})]
         peerSmart  -peerOpt-
         raw        -data- [...]
         regBulk    -list-.-peerChn- -addr1:data1- [-addr2:data2-]...
         regSet     [(prep|{exec})] -regName- -value- [-peerChn-]
         reset      noArg
         statusRequest noArg
         teamCall   noArg
         teamCallBat noArg
         tplDel     -tplDel-
         tplSet_0   -tplChan-
         tplSet_self01 -tplPeer-
         unpair     noArg
       lst:
         condition  Smoke Alarm,no alarm,tone off
         peer       self01
         peerOpt    SMOKE_AUSSEN,SMOKE_BAD,SMOKE_KINDERZIMMER,SMOKE_WOHNZIMMER,VIRTUAL_ACTOR_Btn1,vccu
         tplChan   
         tplDel     
         tplPeer   
       rtrvLst:
         cmdList    [({short}|long)]
         deviceInfo [({short}|long)]
         list       [({normal}|full)]
         param      -param-
         reg        -addr- -list- [-peerChn-]
         regList    noArg
         regTable   noArg
         regVal     -addr- -list- [-peerChn-]
         saveConfig [-filename-]
         tplInfo    noArg
     expert:
       def        1
       det        0
       raw        1
       tpl        0
     io:
       flgs       0
       newChn     +23457F,00,00,00
       nextSend   1635877579.19009
       rxt        0
       vccu       vccu
       p:
         23457F
         00
         00
         00
       prefIO:
     mRssi:
       mNo       
     peerIDsH:
       00000000   broadcast
       23457F01   self01
     prt:
       bErr       0
       sProc      0
     q:
       qReqConf   
       qReqStat   
     role:
       chn        1
       dev        1
     rssi:
     shadowReg:
     tmpl:
Attributes:
   IOgrp      vccu
   actCycle   099:00
   actStatus  alive
   alarmDevice Actor
   alarmSettings |set SMOKE_SCHLAFZIMMER alarmOn;define at_SMOKE_SCHLAFZIMMER at +00:05:00 set SMOKE_SCHLAFZIMMER alarmOff|set SMOKE_SCHLAFZIMMER alarmOff|00:21
   autoReadReg 4_reqStatus
   devStateIcon off:secur_smoke_detector .*:secur_smoke_detector@red
   expert     defReg,rawReg
   firmware   1.0
   model      HM-SEC-SD
   msgRepeat  1
   peerIDs    00000000,23457F01
   room       SCHLAFZIMMER
   serialNr   KEQ0709128
   subType    smokeDetector
   webCmd     statusRequest:teamCall:alarmOn:alarmOff


Ich bin mir eigentlich fast sicher, das es vor dem Update noch nicht so war, kann aber auch gern noch mal ein Backup einspielen, um das zu überprüfen...

PS: Nach einem statusRequest steht der state erst auf MISSING ACK und wenig später wieder auf unreachable. Das ist jetzt durchgängig bei allen Rauchmeldern so, einen Hardware Defekt kann ich also ausschliessen.
PSPS: Bei meinen Fenstersensoren oder Heizungsreglern sind mir übrigens keine Unregelmäßigkeiten aufgefallen.

Timmäää

Hi Mumpitzstuff,

diese Updates hier sind nicht im SVN, sondern gehen darüber hinaus. Dein Problem hatte ich letztens auch, dachte es liege an dem hier bezogenen HMLAN-Update, aber nach einem Reboot des FHEM-Servers ging es bei mir wieder und ich habe keine weitere Analyse betrieben.

Es war wie bei dir: Bei allen Geräten unreachable und/oder Missing_ACK.

Gruß,
Tim