HM-CC-RT-DN Schaltprogramm auslesen / löschen / ändern

Begonnen von Andreas_, 05 Dezember 2013, 15:54:41

Vorheriges Thema - Nächstes Thema

Rohan

Hallo Andreas,

Zitat von: Arpt am 19 Dezember 2013, 12:42:25
Auftrag ausgeführt:...

Fein, war aber kein Auftrag ;)
... ich habe da auf der Diskussionsseite zum Wiki-Beitrag etwas rein gestellt. Kannst du ja bei Gelegenheit mal nachschauen(?).

Gruß
Thomas
Fhem auf Mini-ITX mit Celeron 2-Core, HMLAN (> 55 Devices), CUL (FS20 und EM), RFXtrx 433E, Arduino (einige DS18B20), RPi mit 1-Wire (DS2423 für S0-Signale, DS18B20+), RPi/Arduino mit MQ-5 und MQ-9 (CO- und CNG/LPG-Sensor), CO-20 IAQ Sensor

martinp876

Hallo Andreas,

beim RT kann ich die desired-temp nicht auslesen - man muss warten bis er es mitteilt. Das dauert so 3 min. getConfig und clearRegs helfen da nichts.

ZitatBisher konnte ich den Befehl senden und nachts, wenn der nächste Schaltpunkt auf der Temp-lost kam, wurde dann auf 17 Grad zurückgestellt.
Wo muss ich hinschauen / welche Listings soll ich hier posten?
welchen mode hast du? Auto?


ZitatScheinbar sind RT immer im burst modus
nein. Man kann einschalten, dass der RT bei eine Burst aufwacht - register "burstRx"
Um alle Register zu sehen das Attribut expert auf 1 (oder 2) setzen. Setzen geht unabhängig von expert.

Aufwecken muss man dann auch noch. Mit attr burstAccess geht es automatisch, kommando burstXmit macht es 'manuell'.


Zitatman kann aber auch ein Bit setzen, das aber seit dem update nicht mehr zu setzen ist
schon expert probiert?

Gruss Martin

Andreas_

Hallo Martin,

ich habe die RT´s auf Auto-mode.

"burstRx" habe ich gesetzt, hmmm.... es ging ganz einfach ::)

attr burstAccess habe ich nun auch mal gesetzt.... im entsprechenden Device....

Nun beobachte ich mal, was sich tut, wenn ich den desired-temp Befehl verwende,, zunächst am Pc, dann mal wieder mit andFHEM...

-> E S    F U N K T I ON I E R T ! !


Was bisher irgendwie auch nicht funktionierte, war, wenn ich in andFHEM den Schaltplan änderte oder ergänzte.
(der mit z.B. set WZ1_4 tempListMon 08:00 22.5 24:00 17.0  über den PC ans RT gespeicherte wird in andFHEM angezeigt)

Ich konnte das dann speichern und beim refresh war es wieder weg....

-> das habe ich grade noch mal probiert, scheint nun zu funktionieren,,,,

Was etwas nervig ist, ist das manchmal andfhem irgendwelche Devices nicht einlesen kann, keine Ahnung warum....

aber immerhin, es geht voran.... mal sehen, was mich als nächstes beschäftigt!

Ganz herzlichen DANK, Martin!!!!



BananaPi mit Cul-Stick V3
13 x HM-CC-RT-DN firmware 1.4
1 x HM-HM-LC-SW4
9x HM-LC-Bl1-FM
HM-RC-19

kvo1

Hallo Arpt,
>>>ich habe die RT´s auf Auto-mode.
>>>"burstRx" habe ich gesetzt, hmmm.... es ging ganz einfach
>>>attr burstAccess habe ich nun auch mal gesetzt.... im entsprechenden Device....

muss man das auf das ganze Device anwenden oder nur auf den Cannel (4) ?

>>>Man kann einschalten, dass der RT bei eine Burst aufwacht - register "burstRx"
wie geht das ??       set RT regset burstRx ON ???

>>>kommando burstXmit macht es 'manuell'
wie ??                  set burstXmit ON ???

klaus
RPi1: mit CUL: HM-CC-RT-DN,HM-ES-PMSw1-Pl,HM-LC-BL1-FM,HM-LC-Bl1PBU-FM,HM-LC-SW1-PL2,HM-SCI-3-FM,HM-SEC-SC-2,KFM-Sensor
RPi2: Viessmann(optolink) mit 99_VCONTROL.pm,
Cubietruck: Wheezy / Apache / Owncloud
Cubietruck: Armbian(Jessie) / fhem 5.7 / LMS 7.9
RPi3: (Test) mit 7" Touch  &  HM-MOD-RPI-PCB

Andreas_

Hallo Klaus,

hier meine Anleitung, die ich für mich mal gespeichert habe:

Burst Mode einschalten (mein Kanal 4 des devices WZ1 heisst hier WZ1_4):
set WZ1_4 regSet burstRx on
prüfen mit:
get WZ1_4reg burstRx
FHEM Burst mode einschalten:
attr WZ1 burstAccess 1_auto -> das geht nur für das ganze Device, ansonsten gibt es eine Fehlermeldung...

set burstXmit... geht nur ohne parameter... was das genau macht, weiss ich nicht ::)

BananaPi mit Cul-Stick V3
13 x HM-CC-RT-DN firmware 1.4
1 x HM-HM-LC-SW4
9x HM-LC-Bl1-FM
HM-RC-19

martinp876

attr WZ1 burstAccess 1_auto
immer wenn ein Kommando an das device gesendet wird wird sofort probiert einen burst zu starten und zu übertragen

set burstXmit
schickt einen burst und (wenn erfolgreich) hinterher alles was die cmdQueue gespeichert hat.

Wenn man burstAccess=1 hat braucht man burstXmit nicht mehr, es wird automatisch gemacht.

burstXmit kann man performance-sparender nutzen, wenn man erst alle Kommandos absendet und hinterher den Burst. Jeder Burst des HMLAN koster transmit-kapazität - geht auf den 1h timer. Irgendwann kommt dann overload

Gruss Martin

Andreas_

Hallo Martin,

könnte man meine kurze Anleitung für den burst kombiniert mit Deiner Erklärung nicht auch ins WIKI einstellen?
Ich würde das übernehmen.

Übrigens habe ich, nachdem es heute morgen wieder kalt war in der Bude (Wohnzimmer), 3 Regler aussortiert. Sie reagieren nicht auf FHEM. Ich habe zum testen an alle 13 Regler einen desired-temp gesendet, alle haben reagiert, auch die im oberen Stock und weiter entfernten, nur die 3, die im selben Raum wie die Fritzbox sind, nicht.

Auch ein Reset und neu pairen, was funktioniert hatte, konnte die Geräte nicht überzeugen, einen desired-temp zu akzeptieren.....
ein Gerät war "dead", eines hatte NACK, eines CMD_pendings.... und zwar immer wieder... nun gut, das kommt vor..

Vielleicht hab ich die armen Dinger auch totprogrammiert :'(

Meine 99_utils.pm, wo ich meine Funktionen gespeichert hatte, war heute auch "neu", bzw. alles was ich programmiert hatte war weg...
Ich habe mir nun eine 99_Mutils.pm angelegt,,,,
es bleibt spannend....


BananaPi mit Cul-Stick V3
13 x HM-CC-RT-DN firmware 1.4
1 x HM-HM-LC-SW4
9x HM-LC-Bl1-FM
HM-RC-19

martinp876

Anleitung - hm - eine Erklärung der Details könnte man machen. Eine Anleitung ist immer wenn...dann... Es gibt keinen goldenen Weg.

Burst – wie es funktioniert
Burst:
ist ein Verfahren, mit dem Devices aus dem Stromsparmode erweckt werden können.
Schickt ein Sender eine burst sequenz wachen alle burst-empfänger auf und prüfen die Message. Wenn sie betroffen sind bleiben sie eine Zeit lang wach, ansonsten schlafen sie wieder ein.
Man beachte also, dass Senden eines Burst  Energie in ALLEN burst-Empfängern verbraucht, egal ob sie angesprochen sind.
HMLAN und burst:
HMLAN hat ein Sendebudget das über eine Stunde berechnet wird. Burst belastet diese Konto deutlich - so können nicht mehr als 100 bursts /h gesendet werden - dann geht HMLAN in overload Wenn zusätzliche messages gesendet werden sind es entsprechend weniger.
Es ist als nicht vorteilhaft, unnötig bursts zu senden.
Burst devices:
Es gibt Devices, die immer auf burst reagieren und solche bei denen es abgeschaltet werden kann. So reagiert ein Rauchmelder immer auf Burst damit er seine team-kollegen hören kann.
Ein TC oder RT hingegen hat diese Funktion abschaltbar. Per default ist dies ausgeschaltet um Batterie zu sparen. Wenn ein VD gesteuert wird ist der TC ja selbst wach.  Wird er aber mit einem Fensterkontakt gekoppelt muss es eingeschaltet werden – sonst verpasst er die message.
Bei ConditionalBurst devices, also den abschaltbaren gibt es ein Register burstRx mit dem das burst-erwachen eingestellt werden kann.
Sender, die einen burst-aktor erwecken sollen muss man sagen, welcher peer burst  benötigt. Hier kann ggf. das Register peerNeedsBurst nach dem peeren gesetzt werden. FHEM versucht dies automatisch beim Peeren zu erledigen.
Siehe Hminfo kommando  'models' um festzustellen, welche devices welchen mode unterstützen
Attribut burstAccess
Devices, die abschaltbaren burst haben kann man ein attribut bustAccess 1_auto setzen. Es wird beim abschicken eines Kommandos versucht, das Device mit burst zu wecken. Sollte es nicht funktionieren wird gewartet, bis das Device aufwacht (meist reagieren solche Devices auch auf wakeup). Das setzen des Attributs ist angenehm – es werden aber ggf. viele bursts gesendet.
Kommando burstXmit
Mit diesem Kommando, das bei Devices mit contitional-Burst zu Verfügung steht, wird der burst gezielt von User angestossen. Der User schickt erst seine Kommandos an das device. Die Kommandos werden im Command-stack gesammelt. Dann sendet der User ein set burstXmit. Es passiert das gleiche wie be burstAccess. FHEM versucht mittels burst zu wecken und sendet bei Erfolg die Messages aus dem Kommandostack.
Im Gegensatz zu burstAccess ist burstXmit gezielt einsetzbar und kann sparsamer verwendet werden.
FHEM und burst devices
FHEM sende eine burst automatisch mit Kommandos zu Devices, die nur burst unterstützen.

   passt das so? Anmerkungen? Fragen?

Gerber

Hi,

Danke Martin super Erklärung.

Du schreibts das man mit dem HMLAN ein Sendebudget pro Stunde zur Verfügung hat...

Ist dies bei CUL, CUNO auch vorhanden oder nicht ??

MFG Gerber


Andreas_

BananaPi mit Cul-Stick V3
13 x HM-CC-RT-DN firmware 1.4
1 x HM-HM-LC-SW4
9x HM-LC-Bl1-FM
HM-RC-19

Rohan

Hi Arpt,

hmmm...

den Burst-Modus gibt es ja nicht nur beim RT. Evtl. wäre es hilfreich, die Erläuterungen dazu (eben am Beispiel eines RTs) nach hier zu verlagern? Ich könnte natürlich auch eine Diskussion im Fhemwiki anfangen, aber hier dürfte das Publikum für meinen Vorschlag größer sein.

Danke für dein Engagement und Gruß
Thomas
Fhem auf Mini-ITX mit Celeron 2-Core, HMLAN (> 55 Devices), CUL (FS20 und EM), RFXtrx 433E, Arduino (einige DS18B20), RPi mit 1-Wire (DS2423 für S0-Signale, DS18B20+), RPi/Arduino mit MQ-5 und MQ-9 (CO- und CNG/LPG-Sensor), CO-20 IAQ Sensor

Rohan

Hi,

Zitat von: Gerber am 20 Dezember 2013, 18:02:46
Ist dies bei CUL, CUNO auch vorhanden oder nicht ?

Ja, dort ist es auch vorhanden. Siehe Erklärungen hier und hier.

Gruß
Thomas
Fhem auf Mini-ITX mit Celeron 2-Core, HMLAN (> 55 Devices), CUL (FS20 und EM), RFXtrx 433E, Arduino (einige DS18B20), RPi mit 1-Wire (DS2423 für S0-Signale, DS18B20+), RPi/Arduino mit MQ-5 und MQ-9 (CO- und CNG/LPG-Sensor), CO-20 IAQ Sensor

Andreas_

Hallo Thomas,

ich würge ja als Neueinsteiger in fhem und am RT rum. Dank der Hilfe hier
bekomme ich langsam eine Idee vom RT und ergänze deshalb das RT Wiki.
Damit jemand nach mir gesammelt die Infos zum Gerät findet.

Ich möchte so ein wenig von all dem tollen Support, den ich hier erlebe,zurück geben.
Kopier doch einfach das was ich da rein gestellt habe. was überhaupt nur dank Martin möglich war.
Dann gibt es das zwar zweimal im Netz, aber das sollte das Netz aushalten.
Oder gibt es ne Regel im Wiki, die dagegen spricht?
Lg Andreas
BananaPi mit Cul-Stick V3
13 x HM-CC-RT-DN firmware 1.4
1 x HM-HM-LC-SW4
9x HM-LC-Bl1-FM
HM-RC-19

kvo1

Hallo Andrea,

die alternative Schreibweise scheint Problem zu machen...oder es ist ein Hinweis ... siehe fhem.log

Scalar value @_[0] better written as $_[0] at ./FHEM/99_myUtils.pm line 51.
Scalar value @_[1] better written as $_[1] at ./FHEM/99_myUtils.pm line 51.
Scalar value @_[2] better written as $_[2] at ./FHEM/99_myUtils.pm line 51.
Scalar value @_[3] better written as $_[3] at ./FHEM/99_myUtils.pm line 51.
Scalar value @_[4] better written as $_[4] at ./FHEM/99_myUtils.pm line 51.
Scalar value @_[0] better written as $_[0] at ./FHEM/99_myUtils.pm line 53.
Scalar value @_[1] better written as $_[1] at ./FHEM/99_myUtils.pm line 53.
Scalar value @_[2] better written as $_[2] at ./FHEM/99_myUtils.pm line 53.
Scalar value @_[3] better written as $_[3] at ./FHEM/99_myUtils.pm line 53.
Scalar value @_[4] better written as $_[4] at ./FHEM/99_myUtils.pm line 53.
Scalar value @_[0] better written as $_[0] at ./FHEM/99_myUtils.pm line 55.
Scalar value @_[1] better written as $_[1] at ./FHEM/99_myUtils.pm line 55.
Scalar value @_[2] better written as $_[2] at ./FHEM/99_myUtils.pm line 55.
Scalar value @_[3] better written as $_[3] at ./FHEM/99_myUtils.pm line 55.
Scalar value @_[4] better written as $_[4] at ./FHEM/99_myUtils.pm line 55.

klaus
RPi1: mit CUL: HM-CC-RT-DN,HM-ES-PMSw1-Pl,HM-LC-BL1-FM,HM-LC-Bl1PBU-FM,HM-LC-SW1-PL2,HM-SCI-3-FM,HM-SEC-SC-2,KFM-Sensor
RPi2: Viessmann(optolink) mit 99_VCONTROL.pm,
Cubietruck: Wheezy / Apache / Owncloud
Cubietruck: Armbian(Jessie) / fhem 5.7 / LMS 7.9
RPi3: (Test) mit 7" Touch  &  HM-MOD-RPI-PCB

Andreas_

Hallo Klaus,

die Meldung klingt doch durchaus logisch  :). Ich habe keine große Ahnung vom programmieren. Ich habe es so in irgend einer Perl-Anleitung gefunden und ich mache ja nur mein Ding und da tut es,vielleicht auch zufällig,, aber sei doch so gut und probier es so wie Dein System sagt, dann kann ich Deine Version noch im Wiki ergänzen oder die Alternative rauslöschen... Ich danke Dir!

LG Andreas
BananaPi mit Cul-Stick V3
13 x HM-CC-RT-DN firmware 1.4
1 x HM-HM-LC-SW4
9x HM-LC-Bl1-FM
HM-RC-19