autoreadreg und die peerids

[mcfly71]

Guten Tag Gemeinde,

ich hätte mal eine Anfängerfrage, die ich m.H. von google bislang nicht gelöst bekommen habe.
Es geht um die 2 Punkte im Thema.
Wofür genau sind die peerids? Müssen die bei jedem Gerät gesetzt werden? Bzw. muss jedes Gerät ein autoreadreg haben (Ich hatte es so verstanden, dass autoreadreg die peerids dann einträgt ?!?!?

Bislang habe ich in HC's im Climate die Peerids eingetragen (per Hand) mit denen der HC gekoppelt ist (also die VD (define Nr+01) mehr aber auch nicht, also z.B.

attr XXX1_CLIMATE peerIDs 00000000,1C48EE01,
(Climate des HC)


define XXX CUL_HM 1C48EE
attr XXX .devInfo 010100
attr XXX .stc 58
attr XXX actCycle 028:00
attr XXX actStatus alive
attr XXX expert 2_full
:
:
attr XXX peerIDs
attr XXX subType thermostat


Vielleicht könnte man mir den Sinn und den Umgang mit den 2 Punkten der Überschrift etwas näher bringen ? Da wäre ich sehr dankbar.....

Ich hoffe nun nicht, daß diese Frage schon X Mal gestellt wurde.. ich hatte sie jedenfalls nicht gefunden.

VG
mcfly

[martinp876]

autoreadreg soll, je nach level, die register-Kopie in FHEM (incl peerIDs) aktuell halten. Bei Fernbedienungen geht das meist nicht automatisch, da hier Anlernen gedrückt werden muss, FHEM es also nicht voll-automatich kann.
Bei Aktoren und allen,die auf burst oder wakeup reagieren sollte es automatisch funktionieren (auch RC-19...)

Die peerids sind die HMIDs, welche FHEM aus dem Device gelesen hat. Manuelles aendern ist möglich, aber nicht im Sinne des Erfinders.

User koennen peerList nutzen, da dies "lesbar" ist (wird aus peerids generiert). Somit machen renames mir kein Problem;-). Peerids sind in der Gruppe attribut, da sie somit beim save gespeichert werden. Damit kann man die evtl. vielen peers einer RC12 einmal auslesen und nach save hat man es immer zum Bearbeiten bereit. Readings sind nicht so 'haltbar'.

geplanter Ablauf ist (alle devices/channels)
1) peeren mit peerChan
2) lesen der configuration (getConfig, autoreadreg,...)
2a) ggf ist ein 'anlernen' notwendig (RC12, RC4,...)
=> peerIDs sind gelesen, sowie alle Register
3) save -> peerIDs sind gespeichert.

Fragen?
Gruss
Martin


=>  

[mcfly71]

Hmm, ich glaube ja...

da ich keine Fernbdienungen besitze, sondern nur 2 Funktaster (HM-PB-2-WM55)
und die HM-CC-TC und die gekoppelten HM-CC-VD müssen eigentlich nur dort die autoreadreg
drinstehen. Alle andereren benötigen das nicht.
Ich kann also das autoreadreg dort eintragen, warten, evtl. anlernen drücken, save drücken und fertig ???
(Das hatte ich am Anfang mit den TC's probiert, hatte aber nach dem 3 TC nicht mehr so ganz funktioniert, deshalb das manuelle eintragen).
Das autoreadreg kann ich als attribut auch eigentlich immer in der cfg drinstehen lassen !?

Richtig ?

Danke... wieder mal ...

vg
mcfly

[martinp876]

Hallo mcfly,

der WM55 macht 'wakeup' und sollte, wenn er aufwacht die kommandos abarbeiten. Das konnte ich nicht fuer alle Varianten testen, da ich sie nicht habe - und es nicht 100% gleich ist (oder mir die Details fehlen).

Ich kann also das autoreadreg dort eintragen, warten, evtl. anlernen drücken, save drücken und fertig ???

ja, so ist der Plan.

hatte aber nach dem 3 TC nicht mehr so ganz funktioniert

zu welchen Zeitpunkt? TC ist eigentlich relativ gut eingebaut. Einziges Problem, das ich sehen koennte ist, dass alle TCs gleichzeitig abgefragt werden. Ist eben ein Problem: bei allen Devices entzerre ich die Abfrage -aber bei wakeup muss ich reagieren, sobald dieser wach ist.
Generell musst du mit einer Verzögerung rechnen - nach dem Start werden die getConfigs gequeued und gestaffelt gestartet. Dann muss noch auf das Aufwachen der Devices gewartet werden.
==> was war das Problem, wieviele Devices hast du im AutoReadReg und wie lange hast du gewartet?

Das autoreadreg kann ich als attribut auch eigentlich immer in der cfg drinstehen lassen !?

das ist die Idee, so mache ich es.

Gruss Martin

[mcfly71]

Hallo Martin,

ich hatte beim ersten TC ein autoreadreg drinstehen, und danach war nach sagen wir 20 minuten die peerids drin.
Das klappte leider dann nicht mehr später, auch nicht nach langem Warten. Da ich aber vom ersten wusste, dass die Device IDS + 01 (channel) eingetragen wurden, habe ich die per Hand eingetragen.
gekoppelt waren die ja (das kann man ja im TC selbst sehen, im Menu und bei VST usw.), also war es für mich richtig.
Ich habe insgesamt 7 TC's und 12 VD's.
Das neue Anlernen mache ich meistens folgendermassen:
1) autocreate ist immer in den cfg.
2) Neue VD's an Heizung installieren
3) TC1 auf Anlernen, 1. VD auf anlernen -> TC1,VD1 gekoppelt
3) TC1 auf Anlernen, 2. VD auf anlernen -> TC1,VD2 gekoppelt
3) TC1 auf Anlernen, 3. VD auf anlernen -> TC1,VD3 gekoppelt
Alles gekoppelt...
(Bei den Anlern Zyklen hat dabei fhem die Stellantriebe und das TC eingetragen)
4) hmpairForSec 600
5) TC1 nochmal auf anlernen
6) save
7) edit cfg autoreadreg rein
8) neu starten fhem ... warten .. warten .... warten ...
9) wenn die peerids drin waren wieder save
ABER Punkt 9) ging ab dem 2. o. 3. TC irgendwie nicht mehr.....
ABER ich gebe auch zu, dass ich da viel rumexperimentiert hatte..

Somit steuere ich die Heizkörper immer indirekt nur über climate usw. bzw. dem TC
Die VD-Devices benutze ich nur zum Ablesen der Prozentualen Öffnung, um evtl. Heizung an oder aus zu machen..

Zu autoreadreg immer drin lassen:
Das habe ich jetzt, aber laut commandref nur immer die devices selbst, nicht z.B. die climates oder einzelne channels... richtig ?

vg
mcfly

[martinp876]

Hallo mcfly,

hm - mal sehen was mir alles einfaellt:

getConfig und statusRequest werden immer auf eine Entity ausgefuehrt - wobei ich bei einem Channel nur den Channel und bei einem Device auch dessen Channels Abfrage - wird in HM wenn moeglich so gemacht.
=> autoReadReg sollte also nur im Device stehen, sonst wird es unnötig 2-mal gelesen.

Zeitverhalten: autoReadReg werden über ganz CUL_HM in einer queue abgearbeitet. Alle 15sec wird ein Device bearbeitet, dann sollte immer das vorige fertig sein (empitisch ermittelt...). Bei 19 Devices kann es also ~300sec dauern. Bei TCs musst du noch kalkulieren, dass diese nur alle ~2,5min ansprechbar sind. Es koennte also so 10 min dauern.
Anmerkung: ob ein Device noch in der queue haengt kann man aktuell nicht sehen - sollte ich noch einbauen - irgendwo in "protAutoRegQueue" oder so.
Annahme war, dass dies nicht wirklich eilig ist und somit i.O. sein sollte.

Deine Prozedur sollte ok sein. Ich wuerde zwar so nicht machen, sondern:
1) hmpairForSec 600 # der laenger...
2) anlernen bei TC'S und VD's druecken bis die 600sec vorbei sind - muss nicht einzlen sein
3) TC mit VD über set TC1_Climate peerChan 0 VD1 single;set VD1 getConfig
3) TC mit VD über set TC2_Climate peerChan 0 VD2 single;set VD2 getConfig
3) TC mit VD über set TC3_Climate peerChan 0 VD3 single;set VD3 getConfig
4) bei den VDs rumlaufen und anlernen drücken => vd wird gepeert und Config wird gelesen
5) TC wird gepeert spätestens nach 2,5min (oder anlernen)
6) autoReadReg in alle TCs und VDs.
7) save

Kontrolle - entweder einzeln oder
8) define hm HMinfo # einmalig, wenn man dann 'saved'
9)
 - set hm peerXref # zeigt eine Tabelle, wer mit wem gepeert ist
 - set hm peerCheck # prüft, ob etwas seltsam erscheint in den peering Daten (ohne gewaehr;-) )
 - set hm param peerList # zeigt das reading peerList an
10) register und peers sichern. So kann man ggf ein device nach reset oder nach austausch wieder auf diesen Stand setzen.
 - set hm saveConfig
  ==> Achtung: saveConfig ist ein save der register-readings und peers eines Device. Das ist nicht das save von FHEM. Ein FHEM save speichert die Attribute und alles, was FHEM braucht. Aber nichts war man in das Device schreiben koennte, wenn das Device abgeschmiert ist.

HMinfo arbeitet generell auf alle entites im CUL_HM. Über Filter kannst du es einschränken.

Gruss Martin