HM-SEC-SD-2 neu

mgernoth · 21 Mai 2016, 10:54:39

Zitat von: martinp876 am 21 Mai 2016, 08:57:13
Ok, verstanden. Da hast du sicher recht und es kann so nicht bleiben, da es sich herheitsrelevant ist.
Koennte auch auf den alten SD zutreffen.
Ich werde es durchsehen und die entsprechenden readings überprüfen.

Danke

Zitat
Ich für meinen Teil käme nicht auf die Idee ohne virtuellen lead zu arbeiten - wenn das Team aus mehr als einem besteht. Symetrie, Struktur und Wartung.... nee. Nur um ein virtuelles device zu sparen. Wenn virtuelle device eine Berechtigung haben dann hier.
Aber natürlich kann man anderer Ansicht sein

Ich muss zugeben, mir keine grossen Gedanken gemacht zu haben. Ich habe einfach das Wiki (teilweise) gelesen und da wird am Anfang der Weg mit einem physikalischen Lead beschrieben. Den Punkt mit dem virtuellen Lead habe ich dann uebersprungen...

Ich werde hier jetzt auch auf virtuell wechseln.

Danke & Viele Gruesse
Michael

Bytechanger · 21 Mai 2016, 11:49:37

Trotzdem sollte die Gefahr eines nicht weitergegebenen Alarms beachtet werden!
Es gibt bestimmt noch mehr,die einen physischen lead haben, entgegen der Empfehlung.

martinp876 · 21 Mai 2016, 16:35:01

ZitatTrotzdem sollte die Gefahr eines nicht weitergegebenen Alarms beachtet werden!

sagte ich schon - keine Kompromisse bei sicherheitsrelevanten Komponenten.
Ich haben es eingecheckt.
Ich sehe es dennch kritisch - habe es nicht komplett durchschaut.
Beobachtung bei Teamcall: der "alte" Zähler war auf 15, ich habe einen reboot gemacht. Mein Zähler (virtueller Lead) startet wieder bei " 0". Die SDs ignorieren die message bis ich 15 mal gesendet habe. Dann ist die testnummer wieder höher als die letzte korrekte.
Ich sehe das generell kritisch. Gut, dass man den SD nicht die Bat entnehmen kann, dann würde er mit 0 beginnen. Die ersten Alarme würden vom Team ignoriert.
Sollte man den SD reseten könnte es zu Problemen kommen.
Was hat sich eQ3 hier wohl gedacht?

Übrigens? Kommandos an das Team kosten extrem IO-performance. Das sind 6 Bursts. Mit teamcall kann man schnell eine Überschreitung der erlaubtern Sendetokens erreichen.
Also sparsam nutzen (macht eh kaum sinn).

neue Version ist in SVN

Bytechanger · 21 Mai 2016, 17:21:41

Lässt sich der counter nicht persistent speichern? Attribut oder so?
Sonst ist nach einem Update Essig...

Wann wird es als normales update hochgeladen?

martinp876 · 21 Mai 2016, 17:51:29

als erstes empfehle ich noch einmal dringender als normal virtuelle Teamleads zu nutzen. Dann lässt man die Devices in ruhe und kann hoffen, das eQ3 keine Lücken in der Spec hat.
Problematisch wäre dann nur noch das senden eines Alarms vom virtuellen SDLead.
Das kann man testen - Kopfhöher nicht vergessen beim Testen!
Den test kannst du einfach durchführen.

Die MsgNummer zu speichern ist nur begrenzt möglich. Mit etwas Glück klappt es, wenn ich es als Reading speichere. Sollte der Grund des restarts ein Absturz sein hilft dies aber nicht.
Weiter ist unklar, wie "scharf" HM die entscheidung macht. Es schein mir sinnlos auf genau deinen höheren Wert zu setzen. Im Übrigen muss der Wert auch einmal keiner sein, nach 255 wäre sonst schluss.

martinp876 · 21 Mai 2016, 18:03:07

und zur Info: habe bei Stand cnt 19 einen reboot gemacht. Der Teamcall hat mit 01 begonnen und funktioniert.

Da bleibt viel zu testen- wer Lust hat. Ich könnte mir vorstellen, dass der Zähler nicht mit einem der letzten 10 Werte übereinstimmen darf.
Also wenn der Zäher 25 ist sind alles Werte 16 bis 25 tabu. Viel Spass beim testen

mgernoth · 22 Mai 2016, 01:18:37

Hallo Martin,

Zitat von: martinp876 am 21 Mai 2016, 16:35:01
neue Version ist in SVN

Danke, sieht gut aus

(Bis auf die Fehler, die noch von mir stammen).

Im Anhang noch ein Patch, der das Zusammenspiel mit virtuellen TeamLeads fixed (Keys und HM_CMDNR aus DeviceHash) und eine Warning von mir behebt.

Damit die definierten AES-Keys gefunden werden, muss die IOgrp des virtuellen Geraets eine evtl. definierte VCCU enthalten.

Sollte nicht der hoechste definierte Key genutzt werden, kann der entsprechende Schluesselindex im Attribut aesKey des virtuellen Geraets angegeben werden (das fuehrt im Moment aber noch zu der Meldung: aesKey illegal for virtual devices).

Martin: Schau Dir bitte den Patch mal an und pushe ihn ins SVN, falls er OK ist.

Danke & Viele Gruesse
Michael

Bytechanger · 22 Mai 2016, 14:04:24

Hi noch eine Verständnisfrage,

nach einem Neustart von FHEM, werden da vom TeamLead aus Infos von den SD2 gelesen/angefordert?
Ich vermute dies, da zunächst einige Geräte auf Missing ACK stehen. Nach einigen Mintuten geht es wieder.

Wäre wichtig zu wissen, da eine Abfrage jedes Mal Batteriepower kostet, und die Dinger ja nicht gerade günstig sind.
Leere Batterie=neues Gerät = ca. 50 Euro !
Sollten doch 10 Jahre halten, die Geräte.

Gibt es noch etwas, was man beachten sollte in Bezug auf die Lebensdauer der Batterie??

Das Log zeigt

Code Auswählen

 
CUL_HM set EG_Kueche_RM2 statusRequest
2016.05.22 14:05:16 3: wetter_gymnich: Read callback: request type was update retry 0, no headers, body empty, 
Error: read from http://api.wunderground.com:80 timed out
2016.05.22 14:05:17 3: CUL_HM set EG_Wohnzimmer_RM2 statusRequest
2016.05.22 14:05:18 3: CUL_HM set Garagentor statusRequest
2016.05.22 14:05:19 3: CUL_HM set K_Bastelkeller_RM2 statusRequest
2016.05.22 14:05:20 3: CUL_HM set K_Party_RM statusRequest
2016.05.22 14:05:21 3: CUL_HM set K_Treppe_RM2 statusRequest

Lässt sich der statusRequest unterbinden?
Greets

Byte

M_I_B · 22 Mai 2016, 14:20:13

2 Stück CR17450E ca. 12€ und ein Lötkolben

frank · 22 Mai 2016, 14:41:51

autoreadreg abschalten.

Bytechanger · 22 Mai 2016, 17:50:24

Hallo,

also autoReadReg steht wie bei den SD auf 5_readMissing. Ganz aus macht doch keinen Sinn, oder?

@M_I_B: Ist das wirklich so einfach zu tauschen? Dachte die Batts wären im Gehäuse fest. Wenn ein Lötaustausch möglich ist und die Dinger (CR17450E) normal zu bekommen ist ja super!
Also das geht?

Greets

Byte

M_I_B · 22 Mai 2016, 17:52:47

... ja, das geht problemlos. Scroll mal bis auf die ersten Seiten zurück. Dort habe ich bebildert beschrieben, wie man das Ding zerlegt und an die einzelnen Bauteile dran kommt ...

https://forum.fhem.de/index.php/topic,35298.msg437627.html#msg437627

martinp876 · 22 Mai 2016, 17:58:13

1) ja, der Status wird nicht mehr automatisch gelesen wenn man autoReadReg komplett ausschaltet. StatusRequst ist der geringste Level.
Es ist deine Entscheidung, ob du nach einem Restart den Status aller Devices prüfen willst.

2) die Änderungen habe ich eingebaut. Danke.

mgernoth · 22 Mai 2016, 19:26:09

Hallo Martin,

Zitat von: martinp876 am 22 Mai 2016, 17:58:13
2) die Änderungen habe ich eingebaut. Danke.

Danke

War es Absicht, dass ein temCall jetzt nur noch einmal gesendet wird? Darauf reagieren meine SD2s nicht...

Danke & Viele Gruesse
Michael

martinp876 · 22 Mai 2016, 19:47:43

nein, war ein test. sorry.
meine hatten reagiert ... aber ich habe einen repeater eingestellt. Das verfahren ist nicht wirklich transparent.

6 mal burst kostet einiges an IO performance. nun ja, so offt wird man den Alarm nicht auslösen.
da fällt mir ein - nicht getestet:
Device a löst einen alarm aus und wir senden AlarmOff von Device B (Zentrale). da sollen die Pieper ... nun ja nicht ausgehen - oder doch?....
muss ich mal nachdenken. Evtl brauchen wir einen AlarmOffForce?
na besser es tutet. Typisch muss man den Alarm am auslösenden Device abschalten - was sinn macht.
Aber eine Zentrale darf alles - da sitzt jemand der weiss was er tut