HM-MOD-RE-8: alle Kanäle schalten?

[gestein]

Hallo,

ich habe 2 HM-MOD-RE-8 (also 8 Kanal Schaltmodule), bei denen ich gerne die Kanäle in einem notify ausschalten möchte.
Die Kanäle heissen: TW.Bewaesserung_Gelaender, TW.Bewaesserung_GelaenderH, TW.Bewaesserung_Kraeuter usw.

Nun habe ich die 16 Kanäle so ausgeschaltet:

Code Auswählen Erweitern

set TW.Bewaesserung_.* off

Prinzipiell funktioniert das auch.
Allerdings scheint die VCCU bzw. mein HM-MOD-UART damit manchmal ein Problem zu haben, da etliche Kanäle dann nur mehr "set_off" zeigen und der HM-MOD-RE-8 zeigt "Missing Ack.".

Wie schalte ich so viele Kanäle gleichzeitig aus oder ein?

Danke im Voraus
lg, Gerhard

[Pfriemler]

16 Schaltbefehle gleichtzeitig und noch dazu an ein Burst-Device - ich könnte mir vorstellen, dass das schon Probleme mit dem Duty Cycle geben könnte.
Alternative 1: Nur Geräte schalten lassen, deren Status in FHEM nicht bereits wie der gewünschte ist

Code Auswählen Erweitern

set TW.Bewaesserung_.*:FILTER=STATE=on off

Alternative 2: zwei virtuelle Buttons in FHEM definieren (zwei von den maximal 50 in einer VCCU oder in einem eigenen virtual Device) und alle 16 Kanäle mit diesen dual peeren. Danach nur den jeweiligen Ein- oder Aussschaltbutton setzen. Hier wird nur ein Schaltbefehl gesendet auf den alle Aktoren hören und auch mit mit einem ACK antworten.
Das belastet das Sendezeitlimit des HM-IO-Gerätes deutlich weniger.

[gestein]

Hallo Pfriemler,

Danke. Das probiere ich gleich aus.

Und von den virtuellen Buttons habe ich schon mal gelesen, wußte aber bis dato nicht wirklich wozu das gut ist.
Probiere ich auch aus.

lg, Gerhard

[fiedel]

Da du schon einen HM- Aktor hast drängt es sich förmlich auf, alles "on-for-timer" zu schalten.
Besonders bei einer Bewässerung. Dann fällt das Ausschalten weg und die Ausgänge gehen
auch sicher aus.

[Pfriemler]

... oh ja, gerade bei solchen Dingen wäre das als integrierter Auto-Aus sehr nützlich. Nutze ich selbst ja auch so. Der Not-Aus via virtuellem Button ist ja u.U. zusätzlich nützlich.

Bitte beim Re-8 den on-for-timer-Bug beachten: meine Aktoren laufen ca 30% länger als vorgegeben... glaube nicht, dass das inzwischen gefixt wurde.

[Christoph Morrison]

Bitte beim Re-8 den on-for-timer-Bug beachten: meine Aktoren laufen ca 30% länger als vorgegeben... glaube nicht, dass das inzwischen gefixt wurde.

Sind es wirklich ca. 30% länger oder bis zu 30%? Ich habe mehrere Re-8 im Einsatz und konnte letzteres messen, mit einer recht großen Streuung.

[pwlr]

Moin,

Alternative 2: zwei virtuelle Buttons in FHEM definieren (zwei von den maximal 50 in einer VCCU oder in einem eigenen virtual Device) und alle 16 Kanäle mit diesen dual peeren. Danach nur den jeweiligen Ein- oder Aussschaltbutton setzen. Hier wird nur ein Schaltbefehl gesendet auf den alle Aktoren hören und auch mit mit einem ACK antworten.
Das belastet das Sendezeitlimit des HM-IO-Gerätes deutlich weniger.

Eine gute Lösung - toll zu sehen, wie die Kanäle schlagartig und gleichzeitig ausgehen. Die Statusanzeige in fhem kommt dann so langsam hinterher 

Ich habe mal einen RE-8 von mir mit dbLogInclude "gemessen":

Code Auswählen Erweitern

MariaDB [fhem]> select * from history  where DEVICE = 'Memory_01_Sw_01';
+---------------------+-----------------+--------+----------+---------+-------+------+
| TIMESTAMP           | DEVICE          | TYPE   | EVENT    | READING | VALUE | UNIT |
+---------------------+-----------------+--------+----------+---------+-------+------+
| 2020-07-22 14:44:24 | Memory_01_Sw_01 | CUL_HM | pct: 100 | pct     | 100   |      |
| 2020-07-22 14:45:33 | Memory_01_Sw_01 | CUL_HM | pct: 0   | pct     | 0     |      |
| 2020-07-22 14:47:21 | Memory_01_Sw_01 | CUL_HM | pct: 100 | pct     | 100   |      |
| 2020-07-22 14:49:38 | Memory_01_Sw_01 | CUL_HM | pct: 0   | pct     | 0     |      |
| 2020-07-22 14:51:54 | Memory_01_Sw_01 | CUL_HM | pct: 100 | pct     | 100   |      |
| 2020-07-22 14:54:08 | Memory_01_Sw_01 | CUL_HM | pct: 0   | pct     | 0     |      |
+---------------------+-----------------+--------+----------+---------+-------+------+


14:44 bis 14:45 set on-for-timer 60
14:47 bis 14:49 set on-for-timer 120
14:51 bis 14:54 register shOnTime auf 120 und dann set on set <virtual device> postEvent 200

Also ca. 15%, aber die Teile streuen wohl ziemlich. Für längere Zeiten hatte ich keine Geduld...
Moin
Bernd

[martinp876]

Mal eine Effizient-Lösung für wer genau aufpasst. Ich nutze einen Button mit dem ich - ohne Zentrale, mit peering, alles Abends ausschalten will. U.a. auch eine 8-Kanal-Schalter.

Was man wissen muss (Hintergrund): ist ein Senor welcher mit einem Aktor gepeert ist schickt dem Aktor einen Trigger welcher NICHT den Kanal adressiert. Das wird im Aktor zugewiesen
=> der Sensor braucht nur ein Peering mit einem (EINEM) der Kanäle des Aktors
=> Alle Kanäle des Aktors, welche mit dem Sensor gepeert sein sollen müssen das auch sein (bei dir also alle
Damit ich der Lage Herr werden habe ich implementiert, dass man im Sensor den Channel 00 als Peer einstellen kann.

Code Auswählen Erweitern

define myVrt CUL_HM d0000f
set myVrt virtual 1
attr myVrt_Btn1 peerIDs <TWId>00
set  TW.Bewaesserung_Gelaender peerBulk myVrt_Btn1
set TW.Bewaesserung_GelaenderH peerBulk myVrt_Btn1
set TW.Bewaesserung_Kraeuter peerBulk myVrt_Btn1
....

So, jetzt jeden Channel die Anweisung verpassen, was zu tun ist. Beispielsweise mit einem longPress ausschalten mit einen Short-press einschalten. Einschaltdauer festlegbar.
Template definieren

Code Auswählen Erweitern

set hm templateDef SwOnOff OnTime "short on, Long off" lgOffTime:unused lgMultiExec:off lgSwJtOn:off shSwJtDlyOff:on shMultiExec:off shOnTime:p0 shSwJtOn:no lgSwJtDlyOff:off lgOffTimeMode:absolut shSwJtOff:on lgSwJtDlyOn:off shOnTimeMode:absolut shSwJtDlyOn:on lgActionType:jmpToTarget shActionType:jmpToTarget lgSwJtOff:no

Templare zuweisen

set  TW.Bewaesserung_Gelaender  tplSet_myVrt_Btn1  SwOnOff
set  TW.Bewaesserung_GelaenderH tplSet_myVrt_Btn1  SwOnOff
set  TW.Bewaesserung_Kraeuter     tplSet_myVrt_Btn1  SwOnOff
...
set  TW.Bewaesserung_Gelaender  tplPara000_myVrt_Btn1 _both_SwOnOff_OnTime <onTimeInSec>
set  TW.Bewaesserung_GelaenderH tplPara000_myVrt_Btn1 _both_SwOnOff_OnTime <onTimeInSec>
set  TW.Bewaesserung_Kraeuter     tplPara000_myVrt_Btn1 _both_SwOnOff_OnTime <onTimeInSec>
...

nun kannst du mit

Code Auswählen Erweitern

set myVrt_Btn1  pressS
alles einschalten und mit

Code Auswählen Erweitern

set myVrt_Btn1  pressL
ausschalten.

[Pfriemler]

Eine gute Lösung - toll zu sehen, wie die Kanäle schlagartig und gleichzeitig ausgehen. Die Statusanzeige in fhem kommt dann so langsam hinterher 

Ja, das ist ja das tolle - auch bei diversen Aktoren verstreut (also einzelne Geräte): Sie erhalten einen Befehl, auf den sie alle hören und natürlich sofort reagieren. Anschließend melden sie ihren Status an die Zentrale zurück, und zwar alle einzeln - das dauert dann.

Zu der Laufzeit: Ich hatte bisher nur on-for-timer getestet (es sind bei meinen wirklich fast 30%, komisch - gut dass es bei Dir weniger ist). Wenn shOnTime-Aktionen auch (und wie ich sehe, genauso) betroffen sind, muss es ja wohl ein bedeutsames internes Timerproblem im Modul geben. Man darf in diesem Fall sogar verwundert sein, dass eine Kommunikation überhaupt funktioniert.
Ich hatte schon immer das Gefühl, dass dieses Ding eigentlich irgendwo "outgesourct" entwickelt wurde ohne die sonst üblichen Standards. Vermutlich hat die CCU dann einen Korrekturmechanismus übergeholfen bekommen (wie bei einigen anderen buggy Devices auch) statt das Gerät selbst durch eine aktuelle Firmware zu fixen. Wobei ja ein Firmwareupdate bei den Dingern wohl gar nicht geht...?

@martin: Ich glaube, das überfordert sogar mich ... 

[pwlr]

Moin,

... auch bei diversen Aktoren verstreut (also einzelne Geräte)

Stimmt, habe ich beim Feueralarm implementiert. Bei Alarm werden alle Jalousien (Fluchtwege) über den Teamlead hochgefahren und die Lampen zur besseren Orientierung im Qualm angeschaltet - jedenfalls solange noch keine Sicherung rausgeknallt ist. War mir so gar nicht bewußt...

@Martin
das ist ja mal ne Nummer... Falls ich Dich richtig verstanden habe:
Der Sensor ist für den Test bei mir ein virtueller Button (xx_Btn2), den ich mit allen Kanälen des RE-8 gepeert habe. Im attr xx_Btn2 peerIDs steht dann:

Code Auswählen Erweitern

353B1D01,353B1D02,353B1D03,353B1D04,353B1D05,353B1D06,353B1D07,353B1D08
(das sind die Kanäle)


Dann manuelle Änderung des attr xx_Btn2 peerIDs in 353B1D00 (das ist das Device RE-8)
Mit set xx_Btn2 postEvent 200 schalten dann tatsächlich auch alle Kanäle.

Ich nehme mal an, dass mit dieser Lösung die Abarbeitung im Device effektiver ist ?

Moin
Bernd

[Pfriemler]

Moin,Stimmt, habe ich beim Feueralarm implementiert. Bei Alarm werden alle Jalousien (Fluchtwege) über den Teamlead hochgefahren und die Lampen zur besseren Orientierung im Qualm angeschaltet - jedenfalls solange noch keine Sicherung rausgeknallt ist. War mir so gar nicht bewußt...

Siehste, die Lösung war schon im Hause, aber noch nicht bewusst ... 
Das mit dem Feueralarm ist übrigens eine super Sache (geht bei mir nicht, weil andere Hersteller). Hoffentlich gibt es genug Sicherungen für den Fall, dass gerade im brennenden Teil ein Gerät aktiviert wird...

Bei einem Nachbargaragenbrand vor acht Jahren hier hatte der freundlich von mir in die Nachbargarage weitergeleitete Strom meine Garage und deren Torantrieb stromlos gemacht (im Haus war der zugehörige FI herausgesprungen, was glücklicherweise nur in wenigen Kreisen zum Ausfall führte). Ohne die funktionierende Notentriegelung wäre mein Auto mglw. einige Zeit später hinüber gewesen, so konnte ich es noch völlig schadenfrei retten. Qualm und Heißluft hatten bei mir schließlich das obere Viertel der Garage zum Brandsanierungsfall gemacht. (Merke: Brennbare Flüssigkeiten immer auf dem Boden lagern!)

[gestein]

Da du schon einen HM- Aktor hast drängt es sich förmlich auf, alles "on-for-timer" zu schalten.
Besonders bei einer Bewässerung. Dann fällt das Ausschalten weg und die Ausgänge gehen
auch sicher aus.

Ja, die Ventile werden normalerweise auch per on-for-Timer geschaltet.
Alles andere ist mir zu unsicher.

Manchmal muss man das laufende Programm aber unterbrechen (Not-Aus).
Und dann ist die Lösung von Pfriemler natürlich super.

Lg, Gerhard

[martinp876]

@Bernd,

das ist sicher vom Funk her die effizienteste Methode. Über Broadcast könnte man noch etwas herauskitzeln - hat aber Einschränkungen. Also behaupte ich, das ist das Effizienz-maximum.

@Pfriemler und Zweifler:
Das ganze ist nur komplex, wenn man nicht versucht, die Struktur zu verstehen.
1) peeren der Kanäle zu einem BELIEBIGEN! Sensor (button/virtuell/motion-detector...)
2) peeren des Sensor zu den kanälen
1+2) kann man über peerSmart zusammen machen. Das Frontend gibt ggf die Optionen vor.
Note:)  Das effiziente peeren zum Channel 00 sollten alle Zweifer erst einmal ignorieren

==> Nun sind wir gepeert und ein "programm" im Aktor-kanal ist instanziiert, kann also bearbeitet werden. Das sollte noch jedem klar sein.

3) programmieren des Aktor kanals.
3a) Für Masochisten  und Anwender welche keine Verifikation wollen kann das über register-settings passieren
3b) für smarte Anwender nutzt man ein template. Das KANN man erstellen oder man KOPIERT es
     Template zuweisen kann man im Frontend (nach dessen Definition)  über eine pull-down Liste
3.1) das muss für jeden Aktor-channel separat durchgeführt werden - logisch, egal ob register oder template Ansatz

4) Parametrisieren: man (bspw ich) kann das Programm im Aktor nun parametriesieren. Bei "on" setze ich IMMER eine max-zeit. Register-freaks suchen und setzen das Register. Template-anwender nutzen das Template-param kommando welches nach dem Template-zuweisen erscheint.

5) kontrolle
5a) für register-freaks endet der Support hier
5b) Template-anwender prüfen die korrekte Programmierung über config-check.
Die Einstellung der Template-parameter lässt sich über das einstellen des attr "expert" optimieren
Attr <device> expert templ
=> in den Readings steht nun komprimiert die Funktion der Kanal/peer Kombination

6) das Auslösen. Da ich denke, dass die möglichen Kommandos gerne übersehen werden, hier eine Übersicht
6a) press: man similiert den trigger (Tastendruck) eine mit dem Actor-channel gepeerten Sensors (hier Button-type). Anzugeben ist, ob ein short oder long ausgelöst werden soll und welcher peer simuliert werden soll. Bei long kann man noch angeben, wie viele Wiederholungen gemacht werden sollen und in welcher Zeit diese gesendet werden sollen.
pressL und pressS sind die short-cuts zu "press". Sie lassen sich einfach aus dem Frontend per pull-down auslösen
==> man kann also die Reaktion eines Aktor kanals auf den Trigger eines Buttons jederzeit simulieren - oder nutzen
==> der Trigger geht nur an diesen Aktor - alle dessen Kanäle. Egal mit welchen Aktor sonst noch gepeert ist.

6b) event: Ähnlich wie press. Allerdings ist das ein Trigger eine Motion detectors/shutter-kontakts. Es muss also ein "Wert" mitgegeben werden welcher die Helligkeit oder den Zustand des Fensters darstellt.

6c) trgPress: Die Button variante von Press. Das Press eines Buttons wird simuliert.
6c) trgEvent: Die Motion-Detector wird wie bei TrgPress  simuliert.