FHEM Forum

Hallo zusammen,

ich war eine Weile nicht aktiv, deshalb wurde scheinbar mein Account gelöscht...?!

Ich stehe vor einem Problem und anscheinend stehe ich auch auf dem Schlauch.
Meine Recherchen und Versuche brachten leider nix.
Deshalb hab ich die Hoffnung, dass ihr mir eventuell einen Denkanstoß geben oder mich in die richtige Richtung schubsen könnt,
falls ich totalen Mist gemacht habe.

Zum Hintergrund:
Ich habe vier Aktoren.
Wenn ich den einen schalte, sollen die anderen abschalten - und andersherum.
Dabei soll das Icon in der Web-Ansicht von FHEM aktualisert werden.

Zwei Ansätze:
1. Den Schalter manuell im Web-Frontent schalten und dabei einen weiteren set xyz on;; set abc off ausführen -> Keine Ahnung, ob das geht. Hab nichts dazu gefunden.

2. Über ein Notify den Aktor schalten "lassen" und im Anschluss ein set notify_xyz off ausführen.

2. Funktioniert im Prinzip, ABER die Schaltvorgänge dauern sehr lange und FHEM zeigt an Connection lost ...

Nun weiß ich nicht weiter ...


Hier ein Auszug:
############### VENTIL: VORNE
define vVorne CUL_HM xxx01
attr vVorne userattr room_map structexclude
attr vVorne expert 2_raw
attr vVorne model HM-LC-SW4-SM-2
attr vVorne peerIDs 00000000,
attr vVorne subType switch

############### VENTIL: SEITE
define vSeite CUL_HM xxx02
attr vSeite userattr room_map structexclude
attr vSeite expert 2_raw
attr vSeite model HM-LC-SW4-SM-2
attr vSeite peerIDs 00000000,
attr vSeite subType switch

############### VENTIL: HINTEN1
define vHinten1 CUL_HM xxx03
attr vHinten1 userattr room_map structexclude
attr vHinten1 expert 2_raw
attr vHinten1 model HM-LC-SW4-SM-2
attr vHinten1 peerIDs 00000000,
attr vHinten1 subType switch

############### VENTIL: HINTEN2
define vHinten2 CUL_HM xxx04
attr vHinten2 userattr room_map structexclude
attr vHinten2 expert 2_raw
attr vHinten2 model HM-LC-SW4-SM-2
attr vHinten2 peerIDs 00000000,
attr vHinten2 subType switch





############### VORNE SPRENGEN

define vorneSprengen dummy

attr vorneSprengen webCmd ein:aus
attr vorneSprengen eventMap eventMap ein:on aus:off
attr vorneSprengen devStateIcon on:sprinkler_icon@5ECD3C off:sprinkler_icon@808080 .*:sprinkler_icon@F19A38

define vorneSprengen_EIN notify vorneSprengen:on set vVorne on;; set hinten2Sprengen off;; set hinten1Sprengen off;; set seiteSprengen off;;
define vorneSprengen_AUS notify vorneSprengen:off set vVorne off;;

attr vorneSprengen room BEWÄSSERUNG
attr vorneSprengen group 02_Kreise
attr vorneSprengen alias vorne



############### SEITE SPRENGEN

define seiteSprengen dummy

attr seiteSprengen webCmd ein:aus
attr seiteSprengen eventMap eventMap ein:on aus:off
attr seiteSprengen devStateIcon on:sprinkler_icon@5ECD3C off:sprinkler_icon@808080 .*:sprinkler_icon@F19A38

define seiteSprengen_EIN notify seiteSprengen:on set vSeite on;; set hinten2Sprengen off;; set hinten1Sprengen off;; set vorneSprengen off;;
define seiteSprengen_AUS notify seiteSprengen:off set vSeite off;;

attr seiteSprengen room BEWÄSSERUNG
attr seiteSprengen group 02_Kreise
attr seiteSprengen alias Seite



############### HINTEN1 SPRENGEN

define hinten1Sprengen dummy

attr hinten1Sprengen webCmd ein:aus
attr hinten1Sprengen eventMap eventMap ein:on aus:off
attr hinten1Sprengen devStateIcon on:sprinkler_icon@5ECD3C off:sprinkler_icon@808080 .*:sprinkler_icon@F19A38

define hinten1Sprengen_EIN notify hinten1Sprengen:on set vHinten1 on;; set hinten2Sprengen off;; set seiteSprengen off;; set vorneSprengen off;;
define hinten1Sprengen_AUS notify hinten1Sprengen:off set vHinten1 off;;

attr hinten1Sprengen room BEWÄSSERUNG
attr hinten1Sprengen group 02_Kreise
attr hinten1Sprengen alias hinten1



############### HINTEN2 SPRENGEN

define hinten2Sprengen dummy

attr hinten2Sprengen webCmd ein:aus
attr hinten2Sprengen eventMap eventMap ein:on aus:off
attr hinten2Sprengen devStateIcon on:sprinkler_icon@5ECD3C off:sprinkler_icon@808080 .*:sprinkler_icon@F19A38

define hinten2Sprengen_EIN notify hinten2Sprengen:on set vHinten2 on;; set hinten1Sprengen off;; set seiteSprengen off;; set vorneSprengen off;;
define hinten2Sprengen_AUS notify hinten2Sprengen:off set vHinten2 off;;

attr hinten2Sprengen room BEWÄSSERUNG
attr hinten2Sprengen group 02_Kreise
attr hinten2Sprengen alias hinten2

Liebe Grüße


EDIT:

Die Steuerung habe ich mit Hilfe von Otto und TomLee nun fertig bekommen.
Ich habe viel dabei gelernt und Inspiration und wertvolle Erkenntnisse für zukünftige Optimierungen meiner bestehenden Automatisierungen erlangt.

Vielen lieben und aufrichtigen Dank nochmals!

Hier der fertige, für meine Bedürfnisse sehr gut funktionierende Code:


#################################################################################################### PUMPE

define a_Pumpe CUL_HM xxxxxA02
attr a_Pumpe userattr room_map structexclude
attr a_Pumpe model HM-LC-SW4-SM
attr a_Pumpe peerIDs 00000000,

attr a_Pumpe alias Pumpe

attr a_Pumpe webCmd ein:aus
attr a_Pumpe eventMap on:ein off:aus
attr a_Pumpe devStateIcon ein:sani_domestic_waterworks@5ECD3C aus:sani_domestic_waterworks@808080 .*:sani_domestic_waterworks@F19A38

attr a_Pumpe room BEWÄSSERUNG
attr a_Pumpe group 02_Kreise

#################################################################################################### PUMPE ENDE





#################################################################################################### VENTILE

define a_VentilVorne CUL_HM xxxxx001
attr a_VentilVorne userattr room_map structexclude
attr a_VentilVorne model HM-LC-SW4-SM-2
attr a_VentilVorne peerIDs 00000000,

define a_VentilSeite CUL_HM xxxxx002
attr a_VentilSeite userattr room_map structexclude
attr a_VentilSeite model HM-LC-SW4-SM-2
attr a_VentilSeite peerIDs 00000000,

define a_VentilHinten1 CUL_HM xxxxx003
attr a_VentilHinten1 userattr room_map structexclude
attr a_VentilHinten1 model HM-LC-SW4-SM-2
attr a_VentilHinten1 peerIDs 00000000,

define a_VentilHinten2 CUL_HM xxxxx004
attr a_VentilHinten2 userattr room_map structexclude
attr a_VentilHinten2 model HM-LC-SW4-SM-2
attr a_VentilHinten2 peerIDs 00000000,

attr a_VentilVorne alias vorne
attr a_VentilSeite alias Seite
attr a_VentilHinten1 alias hinten1
attr a_VentilHinten2 alias hinten2

attr a_Ventil.* webCmd ein:aus
attr a_Ventil.* eventMap on:ein off:aus
attr a_Ventil.* devStateIcon ein:sani_sprinkling@5ECD3C aus:sani_sprinkling@808080 .*:sani_sprinkling@F19A38

attr a_Ventil.* room BEWÄSSERUNG
attr a_Ventil.* group 02_Kreise

define n_Ventil notify a_Ventil.*:on set a_Ventil.*:FILTER=NAME!=$NAME off;;

#################################################################################################### VENTILE ENDE

attr a_Pumpe sortby 1
attr a_VentilVorne sortby 2
attr a_VentilSeite sortby 3
attr a_VentilHinten1 sortby 4
attr a_VentilHinten2 sortby 5





#################################################################################################### 00_SCHNELLZUGRIFFE

define d00_PumpeSprengen_10 dummy
define d00_VorneSprengen_10 dummy
define d00_SeiteSprengen_10 dummy
define d00_Hinten1Sprengen_10 dummy
define d00_Hinten2Sprengen_10 dummy

attr d00_PumpeSprengen_10 alias Pumpe für 10 min. einschalten
attr d00_VorneSprengen_10 alias vorne für 10 min. sprengen
attr d00_SeiteSprengen_10 alias Seite für 10 min. sprengen
attr d00_Hinten1Sprengen_10 alias hinten1 für 10 min. sprengen
attr d00_Hinten2Sprengen_10 alias hinten2 für 10 min. sprengen

attr d00_.* webCmd ein
attr d00_.* devStateIcon ein:time_timer@367BF6:ein .*:time_timer@F19A38

attr d00_.* room BEWÄSSERUNG
attr d00_.* group 00_Schnellzugriffe

define n00_PumpeSprengen_10 notify d00_PumpeSprengen_10:ein set a_Pumpe on-for-timer 600;;
define n00_VorneSprengen_10 notify d00_VorneSprengen_10:ein set a_VentilVorne on-for-timer 600;; set a_Pumpe on-for-timer 600;;
define n00_SeiteSprengen_10 notify d00_SeiteSprengen_10:ein set a_VentilSeite on-for-timer 600;; set a_Pumpe on-for-timer 600;;
define n00_Hinten1Sprengen_10 notify d00_Hinten1Sprengen_10:ein set a_VentilHinten1 on-for-timer 600;; set a_Pumpe on-for-timer 600;;
define n00_Hinten2Sprengen_10 notify d00_Hinten2Sprengen_10:ein set a_VentilHinten2 on-for-timer 600;; set a_Pumpe on-for-timer 600;;

#################################################################################################### 00_SCHNELLZUGRIFFE ENDE

attr d00_PumpeSprengen_10 sortby 1
attr d00_VorneSprengen_10 sortby 2
attr d00_SeiteSprengen_10 sortby 3
attr d00_Hinten1Sprengen_10 sortby 4
attr d00_Hinten2Sprengen_10 sortby 5





#################################################################################################### 01_ZEITPROGRAMME

define d01_MorgensSprengen dummy
define d01_AbendsSprengen dummy

attr d01_MorgensSprengen alias morgens komplett sprengen
attr d01_AbendsSprengen alias abends komplett sprengen

attr d01_.* webCmd ein:aus
attr d01_.* eventMap ein:on aus:off
attr d01_.* devStateIcon on:ios-on-green off:ios-off .*:ios-NACK:off

attr d01_.* room BEWÄSSERUNG
attr d01_.* group 01_Zeitprogramme

define at01_MorgensSprengen_Pumpe at *05:00 set a_Pumpe on-for-timer 2700;;
define at01_MorgensSprengen_Vorne at *05:00 set a_VentilVorne on-for-timer 900;;
define at01_MorgensSprengen_Seite at *05:15 set a_VentilSeite on-for-timer 900;;
define at01_MorgensSprengen_Hinten1 at *05:30 set a_VentilHinten1 on-for-timer 900;;
define at01_MorgensSprengen_Hinten2 at *05:45 set a_VentilHinten2 on-for-timer 900;;

define at01_AbendsSprengen_Pumpe at *21:00 set a_Pumpe on-for-timer 5400;;
define at01_AbendsSprengen_Vorne at *21:00 set a_VentilVorne on-for-timer 1800;;
define at01_AbendsSprengen_Seite at *21:30 set a_VentilSeite on-for-timer 1800;;
define at01_AbendsSprengen_Hinten1 at *22:00 set a_VentilHinten1 on-for-timer 1800;;
define at01_AbendsSprengen_Hinten2 at *22:30 set a_VentilHinten2 on-for-timer 1800;;

define n01_MorgensSprengen_EIN notify d01_MorgensSprengen:on set at01_Morgens.* active;;
define n01_MorgensSprengen_AUS notify d01_MorgensSprengen:off set at01_Morgens.* inactive;;

define n01_AbendsSprengen_EIN notify d01_AbendsSprengen:on set at01_Abends.* active;;
define n01_AbendsSprengen_AUS notify d01_AbendsSprengen:off set at01_Abends.* inactive;;

#################################################################################################### 01_ZEITPROGRAMME ENDE

attr d01_MorgensSprengen sortby 1
attr d01_AbendsSprengen sortby 2






EDIT:

Es hat sich viel getan.
Hier meine komplette Steuerung - Stand 18. Juli 2021

#################################################################################################### DEVICES

define schalter_Pumpe HMCCUCHN NEQxxxxxxx:2
attr schalter_Pumpe alias Pumpe

attr schalter_Pumpe webCmd ein:aus
attr schalter_Pumpe eventMap on:ein off:aus
attr schalter_Pumpe devStateIcon ein:sani_domestic_waterworks@5ECD3C aus:sani_domestic_waterworks@808080 .*:sani_domestic_waterworks@F19A38

attr schalter_Pumpe room BEWÄSSERUNG
attr schalter_Pumpe group 02_Kreise (manuelle Steuerung)



define schalter_Ventil1 HMCCUCHN QEQxxxxxxx:1
attr schalter_Ventil1 alias vorne + Seite

define schalter_Ventil2 HMCCUCHN QEQxxxxxxx:2
attr schalter_Ventil2 alias Hecke + Beet

define schalter_Ventil3 HMCCUCHN QEQxxxxxxx:3
attr schalter_Ventil3 alias hinten1

define schalter_Ventil4 HMCCUCHN QEQxxxxxxx:4
attr schalter_Ventil4 alias hinten2

attr schalter_Ventil.* webCmd ein:aus
attr schalter_Ventil.* eventMap on:ein off:aus
attr schalter_Ventil.* devStateIcon ein:sani_sprinkling@5ECD3C aus:sani_sprinkling@808080 .*:sani_sprinkling@F19A38

attr schalter_Ventil.* room BEWÄSSERUNG
attr schalter_Ventil.* group 02_Kreise (manuelle Steuerung)



#################################################################################################### SCHNELLZUGRIFFE

define dummy_Wasser_Anfeuchten dummy
attr dummy_Wasser_Anfeuchten alias Rasen anfeuchten (Nachsaat)

define dummy_Wasser_Zapf_EIN_30 dummy
attr dummy_Wasser_Zapf_EIN_30 alias Zapfstelle für 30 min. einschalten

define dummy_Wasser_SchnellSprengen dummy
attr dummy_Wasser_SchnellSprengen alias jetzt für 15 min. sprengen/wässern

attr dummy_Wasser_.* webCmd ein
attr dummy_Wasser_.* devStateIcon ein:time_timer@367BF6:ein .*:time_timer@F19A38

attr dummy_Wasser_.* room BEWÄSSERUNG
attr dummy_Wasser_.* group 00_Schnellzugriffe

define notify_Wasser_Anfeuchten notify dummy_Wasser_Anfeuchten:ein { fhem ("set schalter_Ventil.* off;; set schalter_Pumpe on-for-timer 900;; set schalter_Ventil1 on-for-timer 300;; sleep 300;; set schalter_Ventil3 on-for-timer 300;; sleep 300;; set schalter_Ventil4 on-for-timer 300;;") }
define notify_Wasser_Zapf_EIN_30 notify dummy_Wasser_Zapf_EIN_30:ein { fhem ("set schalter_Ventil.* off;; set schalter_Pumpe on-for-timer 1800;;") }
define notify_Wasser_SchnellSprengen notify dummy_Wasser_SchnellSprengen:ein { fhem ("set schalter_Ventil.* off;; set schalter_Pumpe on-for-timer 3600;; set schalter_Ventil4 on-for-timer 900;; sleep 900;; set schalter_Ventil3 on-for-timer 900;; sleep 900;; set schalter_Ventil1 on-for-timer 900;; sleep 900;; set schalter_Ventil2 on-for-timer 900;;") }



#################################################################################################### ZEITPLAENE

define at_BewaesserungAuto at *{(ReadingsVal('dummy_Bewaesserung_aktiv','start','19:19'))} { \
my $next = (ReadingsVal('dummy_Bewaesserung_next','state',''));; \
my $dauer_VorneSeite = (ReadingsVal('dummy_BewaesserungAuto_VorneSeite','state','') * 60);; \
my $dauer_Hinten1 = (ReadingsVal('dummy_BewaesserungAuto_Hinten1','state','') * 60);; \
my $dauer_Hinten2 = (ReadingsVal('dummy_BewaesserungAuto_Hinten2','state','') * 60);; \
my $dauer_HeckeBeet = (ReadingsVal('dummy_BewaesserungAuto_HeckeBeet','state','') * 60);; \
my $dauer_total = ($dauer_VorneSeite + $dauer_Hinten1 + $dauer_Hinten2 + $dauer_HeckeBeet);; \
if ($next eq 'heute') \
{ fhem (" \
set schalter_Pumpe off;; \
set schalter_Ventil.* off;; \
set dummy_Bewaess_lief on;; \
set schalter_Pumpe on-for-timer $dauer_total;; \
set schalter_Ventil4 on-for-timer $dauer_Hinten2;; \
sleep $dauer_Hinten2;; \
set schalter_Ventil3 on-for-timer $dauer_Hinten1;; \
sleep $dauer_Hinten1;; \
set schalter_Ventil1 on-for-timer $dauer_VorneSeite;; \
sleep $dauer_VorneSeite;; \
set schalter_Ventil2 on-for-timer $dauer_HeckeBeet;; \
")};;}

define at_Bewaesserung_next at +*01:00 { \
my $active = (ReadingsVal('dummy_Bewaesserung_aktiv','state',''));; \
my $tage = (ReadingsVal('dummy_Bewaesserung_aktiv','tage',''));; \
my $then = (ReadingsTimestamp('dummy_Bewaess_lief', 'state', ''));; \
my $next1 = (time_str2num($then) + $tage * 60 * 60 * 24);; \
my $next2 = strftime("%Y-%m-%d",localtime($next1));; \
my $now = (strftime("%Y-%m-%d",localtime(time)));; \
my $diff1 = (((((time_str2num($next2)) - (time_str2num($now))) / 60) / 60) / 24);; \
my $nextDay = (strftime('%A',localtime(time+3600*24*$diff1)));; \
if ($active eq 'on') { \
if ($diff1 <= 0) {fhem("set dummy_Bewaesserung_next heute;;")};; \
if ($diff1 == 1) {fhem("set dummy_Bewaesserung_next morgen;;")};; \
if ($diff1 == 2) {fhem("set dummy_Bewaesserung_next übermorgen;;")};; \
if ($diff1 >= 3) {fhem("set dummy_Bewaesserung_next $nextDay;;")};; } \
else { {fhem("set dummy_Bewaesserung_next -;;")} };; }

attr at_BewaesserungAuto computeAfterInit 1



#################################################################################################### ZEITPROGRAMME

define dummy_Bewaesserung_aktiv dummy
attr dummy_Bewaesserung_aktiv alias aktiv

defmod dummy_BewaesserungAuto_VorneSeite dummy
attr dummy_BewaesserungAuto_VorneSeite alias vorne + Seite

defmod dummy_BewaesserungAuto_Hinten1 dummy
attr dummy_BewaesserungAuto_Hinten1 alias hinten1

defmod dummy_BewaesserungAuto_Hinten2 dummy
attr dummy_BewaesserungAuto_Hinten2 alias hinten2

defmod dummy_BewaesserungAuto_HeckeBeet dummy
attr dummy_BewaesserungAuto_HeckeBeet alias Hecke + Beet

define dummy_Bewaess_lief dummy
define dummy_Bewaesserung_next dummy
attr dummy_Bewaesserung_next alias nächster Lauf



attr dummy_Bewaesserung_aktiv readingList state start tage
attr dummy_Bewaesserung_aktiv setList state:on,off \
start:19:00,19:30,20:00,20:30,21:00,21:30,22:00,22:30,23:00,01:00,01:30,02:00,02:30,03:00,03:30,04:00,04:30,05:00 \
tage:1,2,3,4,5,6,7

attr dummy_Bewaesserung_aktiv webCmd :start:tage
attr dummy_Bewaesserung_aktiv webCmdLabel :Start:Tage
attr dummy_Bewaesserung_aktiv devStateIcon on:ios-on-green:off off:ios-off:on .*:ios-NACK:off

define notify_Bewaesserung_aktiv_EIN notify dummy_Bewaesserung_aktiv.on { fhem ("set at_BewaesserungAuto active") }
define notify_Bewaesserung_aktiv_AUS notify dummy_Bewaesserung_aktiv.off { fhem ("set at_BewaesserungAuto inactive") }
define notify_Bewaesserung_aktiv notify dummy_Bewaesserung_aktiv { \
fhem ("set at_BewaesserungAuto modifyTimeSpec {(ReadingsVal('dummy_Bewaesserung_aktiv','start',''))};; set at_Bewaesserung_next execNow;;") }



attr dummy_BewaesserungAuto_.* readingList state
attr dummy_BewaesserungAuto_.* setList state:15,30,45,60,90

attr dummy_BewaesserungAuto_.* webCmd state
attr dummy_BewaesserungAuto_.* webCmdLabel Dauer

attr dummy_BewaesserungAuto_.* stateFormat state min.

attr dummy_Bewaesserung.* room BEWÄSSERUNG
attr dummy_Bewaesserung.* group 01_Zeitprogramme (autom. sprengen/wässern)



#################################################################################################### SORT

attr dummy_Wasser_Zapf_EIN_30 sortby 1
attr dummy_Wasser_SchnellSprengen sortby 2
attr dummy_Wasser_Anfeuchten sortby 3

attr schalter_Pumpe sortby 1
attr schalter_Ventil1 sortby 2
attr schalter_Ventil3 sortby 3
attr schalter_Ventil4 sortby 4
attr schalter_Ventil2 sortby 5

attr dummy_Bewaesserung_aktiv sortby 1
attr dummy_Bewaesserung_next sortby 2
attr dummy_BewaesserungAuto_VorneSeite sortby 3
attr dummy_BewaesserungAuto_Hinten1 sortby 4
attr dummy_BewaesserungAuto_Hinten2 sortby 5
attr dummy_BewaesserungAuto_HeckeBeet sortby 6



#################################################################################################### TASTER

define PB61_5 HMCCUCHN OEQxxxxxxx:5
define notify_PB61_5_SHORT notify PB61:5.PRESS_SHORT.* { fhem ("set schalter_Ventil.* off;; set schalter_Pumpe on;;") }
define notify_PB61_5_LONG notify PB61:5.PRESS_LONG.* { fhem ("set schalter_Ventil.* off;; set schalter_Pumpe off;;") }


Na dann mal wilkommen zurück.

Normalerweise bekommt man eine Benachrichtigung, bevor man als User gelöscht wird und muss sich dann nur wieder einmalig anmelden, dann hat man längere Zeit wieder Ruhe (ein Jahr oder so).

Mehrere Schaltvorgänge kann man schon "miteinander" raushauen, kein Problem, siehe https://fhem.de/commandref_modular.html#command:

ZitatMultiple FHEM commands are separated by semicolon (;). In order to use semicolon in perl code or shell programs, they have to be escaped by the double semicolon (;;). See the Notes section of the notify (https://fhem.de/commandref_modular.html#notify) chapter on command parameters and escape rules.

Das notify-Thema ist ein Anfängerthema, aber das würde ich erst mal hintanstellen, denn:

- Das mit "Connection lost" etc. klingt aber nach einem Homematic-Spezifischen Problem, von daher würde ich empfehlen, den Thread dahin zu verschieben oder dort einen neuen aufzumachen, um diesen Aspekt zu beleuchten. "list"-Auszüge von einem der Devices und dem betreffenden IO (und der VCCU, falls es eine gibt) solltest du aber beifügen;
- Bei HM gibt es auch die Möglichkeit, interne Abhängigkeiten im Aktor selbst festzulegen. Da du scheinbar immer nur einen Kanal von einem 4-Kanaligen Aktor "on" haben willst/musst, wäre die beste Variante, das direkt dort zu erledigen. Dazu muss man - so das überhaupt machbar ist - Registerwerte bearbeiten. Hilfe dafür findest du aber (ggf. in einem gesonderten Thread) eher direkt bei den Homematic-Spezialisten.

(Hoffe, das ist verständlich...)
Und noch eine OT-Anmerkung: fhem.cfg-Auszüge will hier heutzutage keiner mehr sehen. "list" oder "list -r" sind deutlich aufschlussreicher, und der Verdacht kommt dann auch nicht auf, du würdest die cfg direkt bearbeiten...

Hi,

die Beschreibung von 2 klingt nach einem Loop - schau am Besten mal Eventmonitor was da passiert.

Gruß Otto

Klingt ein wenig wie das hier: https://forum.fhem.de/index.php/topic,115191.msg1094530.html#msg1094530
EDIT: hier halt mit 4 Geräten ;)

@Otto: das habe ich mir auch gedacht...

Evtl. ist mit "connection lost" die "Anzeige" im Browser gemeint... Also so ein "Popup"... Das würde dann evtl. zu "langsam" und "Schleife" passen ;)

Gruß, Joachim

Vorschlag zur Lösung:
Komplettes Szenario zum Testen:
define Aktor1 dummy
define Aktor2 dummy
define Aktor3 dummy
define Aktor4 dummy
attr Aktor. room Test
define n_Aktorx notify Aktor.:on set Aktor.:FILTER=NAME!=$NAME {(("$EVENT" eq 'on')?'off':'on')}
attr n_Aktorx disabledAfterTrigger 1
attr n_Aktorx room Test

Das notify reagiert auf jeden AktorX aber nur auf on! Damit es nicht auf sich selbst reagiert wird es 1 Sekunde pausiert!
Das devSpec Aktor.:FILTER=NAME!=$NAME ergibt alle AktorX außer den Auslöser
Der set magic {Perl} Code macht aus dem Event on ein off (geht vielleicht auch anders?) bzw. Ich hatte an: aus on mach off und aus off mach on gedacht. Wenn die Gegenrichtung nicht gebraucht wird: ersetze den kompletten Ausdruck durch off!

defmod n_Aktorx notify Aktor.:on set Aktor.:FILTER=NAME!=$NAME off

Edit: Sorry, ich habe mir durch die komische Darstellung (Lücke in dem Code) heut nachmittag gar nicht alles angeschaut und nicht weiter gescrollt - nicht gesehen -
Aber ich denke durch meine Idee sparst Du eine Menge: Du hast nur die Ventile, keine Dummies und nur ein notify welches Deine Aufgabe erfüllt. Vielleicht benennst Du die Ventile um, da wird das devSpec einfacher. Mit Deinen Namen wird es unnötig kompliziert ;)

Gruß Otto 

Vielen lieben Dank für eurer Rückmeldungen. Das ist erstmal etwas Stoff zum Ansetzten. Ich werde das die Tage mal ausprobieren, wobei ich noch ein paar Verständnisprobleme habe ...

Zitat von: remo am 05 Dezember 2020, 14:04:40
wobei ich noch ein paar Verständnisprobleme habe ...

frag ruhig ;)

Komme ich drauf zurück. Aber ich versuche es erstmal alleine  :D

Vielen lieben Dank für die Anregungen.

Otto, ich habe später soetwas vor wie

set vorneSprengen on-for-timer 900

Mittlerweile erscheint mir dein Vorschlag schlüssig, auch wenn ich ihn noch nicht testen konnte.
Aber ob mit deinem Vorschlag ein on-for-timer möglich ist, erkenne ich auf den ersten und zweiten Blick leider nicht...

Liebe Grüße und einen schönen zweiten Advent!

Ja: weil on-for-timer am Ende auch bloß den on Event liefert (gilt für CUL_HM Geräte)
schau dir im Event Monitor an:

Zitat2020-12-05 18:11:08 CUL_HM SD3 commState: CMDs_pending
2020-12-05 18:11:08 CUL_HM SD3 set_on-for-timer 4
2020-12-05 18:11:08 CUL_HM SD3 commState: CMDs_done
2020-12-05 18:11:08 CUL_HM SD3 deviceMsg: on (to VCCU)
2020-12-05 18:11:08 CUL_HM SD3 level: 100
2020-12-05 18:11:08 CUL_HM SD3 pct: 100
2020-12-05 18:11:08 CUL_HM SD3 on
2020-12-05 18:11:08 CUL_HM SD3 timedOn: running
2020-12-05 18:11:14 CUL_HM SD3 deviceMsg: off (to broadcast)
2020-12-05 18:11:14 CUL_HM SD3 level: 0
2020-12-05 18:11:14 CUL_HM SD3 pct: 0
2020-12-05 18:11:14 CUL_HM SD3 off
2020-12-05 18:11:14 CUL_HM SD3 timedOn: off

Auf den Event reagiert das notify

Ok. Vielleicht schaffe ich morgen Vormittag mal deine Vorschläge zu testen. Danke dir.

ZitatVorschlag zur Lösung:
Komplettes Szenario zum Testen:

Damit komme ich irgendwie nicht weiter...
Ich kann weder Aktor1-4 noch den Notify n_Aktorx schalten ...

Naja das notify schaltest nicht Du (ich befürchte immer in deinen Worten Du hast das  vor) das notify reagiert auf Evnets.

Du hast das so definiert wie oben in meinem Code? Dann machst du set Aktor1 on und nichts passiert?

ZitatDann machst du set Aktor1 on und nichts passiert?

Sorry, doch. Funktioniert.

set Aktor<#> on

schaltet den entspr. Dummy und alle anderen aus!
So wie es sein soll.

Ich konnte den Code auch schon so anpassen, dass keine Dummys sondern die tatsächlichen Aktoren schalten.

mit

set ventil<KREIS> on


funktioniert es zumindest manuell über das Eingabefeld in FHEM.

Jetzt würde ich das gerne mit webCmd, eventMap und devStateIcon realisieren.

ZitatJetzt würde ich das gerne mit webCmd, eventMap und devStateIcon realisieren.

Geht ja schon über die Ventile selbst!

Edit: soweit, so gut!

Vielen Dank bis dahin!


Ventile schalten ist super - klappt auch.

Zwei weitere Baustellen zu diesem Thema:

1. bei einem Klick auf zB "ventilSeite", soll zusätzlich im Anschluss ein weiterer Aktor geschaltet werden (die Pumpe)
2. ein on-for-timer für zB "ventilHinten1 on" und "Pumpe on" möchte ich mir gerne auch noch basteln.

Dazu zwei Ideen:
Entweder einfach in diesem notify den zweiten Befehl set pumpe on
also:set Aktor.:FILTER=NAME!=$NAME off;;set pumpe on

Oder wenn Du den Timer nur an den Ventile festlegen willst machst Du ein weiteres Gerät welches bei allen Ventilen auf timedOn reagiert
Die Idee ist ungetestet!
2020-12-05 18:11:08 CUL_HM SD3 timedOn: running
2020-12-05 18:11:14 CUL_HM SD3 timedOn: off

Gruß Otto

Ich habe mir das Konstrukt mit webCmd, eventMap und devStateIcon hübsch machen können.

Aber: selber "Fehler" wie zuvor:
langsame Auslösezeiten und "Connection Lost" als PopUp in der oberen linken Ecke und die Seite aktualisiert sich nicht.
Lasse ich webCmd, eventMap und devStateIcon raus und schalte die Ventile manuell über das Eingabefeld, ist alles bestens ...

Dein ursprünglicher Code ist noch aktiv?

ZitatDein ursprünglicher Code ist noch aktiv?

nein.

Vielleicht hilft das:

############### VENTIL: HINTEN2
define ventilHinten2 CUL_HM xxx04
attr ventilHinten2 userattr room_map structexclude
attr ventilHinten2 expert 2_raw
attr ventilHinten2 model HM-LC-SW4-SM-2
attr ventilHinten2 peerIDs 00000000,
attr ventilHinten2 subType switch

attr ventilHinten2 webCmd ein:aus
attr ventilHinten2 eventMap on:ein off:aus
attr ventilHinten2 devStateIcon ein:sprinkler_icon@5ECD3C aus:sprinkler_icon@808080 .*:sprinkler_icon@F19A38

attr ventilHinten2 room BEWÄSSERUNG
attr ventilHinten2 group 02_Kreise
attr ventilHinten2 alias hinten2



define n_Aktorx notify ventil.*:on set ventil.*:FILTER=NAME!=$NAME {(("$EVENT" eq 'on')?'off':'on')}
attr n_Aktorx disabledAfterTrigger 1

Nur mal zur Kontrolle, was sagt list ventil.*

Es klingt so, als schickst Du dein FHEM in eine zeitliche Schleife und die Weboberfläche reagiert nicht mehr.
Ich habe ja nie behauptet, dein ursprünglicher Code ist der Grund - mir war der nur zu kompliziert ;)

Also da ist was, was auf die Aktion die Du ausführst reagiert und eine Schleife läuft. Siehst Du was im Eventmonitor oder im Log? Hast Du freezmon aktiv?

list

Listet sauber alle vier Ventile auf.

Freezmon hab ich nicht aktiviert.

Das EventLog ist unauffällig: es erscheint zumindest nix doppelt.

Es scheint auch nur in einen Loop zu laufen wenn ich die Aktoren über das Web mit eventMap, webCmd und decStateIcon schalte. Also wenn ich diese drei Zeilen rauskommentiere und manuell über das Textfeld set ventilX on eingeben, geht's. Sind die drei Zeilen aktiv und ich schalte mit der Maus über das Web, geht's nicht.

set ventilVorne on
set ventilHinten1 on

usw.

als manuelle Eingabe über das Textfeld funktioniert.
Nach jedem Enter refresht die Seite und alles ist gut.
Auch wenn es ziemlich träge ist...

Klicke ich hingegen auf die Aktoren (webCmd) dauert der Schaltvorgang lange und es erscheint "Connection Lost"...
Nach 5 Sekunden fängt sich die Seite meist aber wieder.
Schön ist das aber nicht.


Hier nochmal der aktuelle Code (auch wenn das nicht allzu gerne gesehen ist):

############### VENTIL: VORNE
define ventilVorne CUL_HM 001
attr ventilVorne userattr room_map structexclude
attr ventilVorne expert 2_raw
attr ventilVorne model HM-LC-SW4-SM-2
attr ventilVorne peerIDs 00000000,
attr ventilVorne subType switch

attr ventilVorne webCmd ein:aus
attr ventilVorne eventMap on:ein off:aus
attr ventilVorne devStateIcon ein:sprinkler_icon@5ECD3C aus:sprinkler_icon@808080 .*:sprinkler_icon@F19A38

attr ventilVorne room BEWÄSSERUNG
attr ventilVorne group 02_Kreise
attr ventilVorne alias vorne



############### VENTIL: SEITE
define ventilSeite CUL_HM 002
attr ventilSeite userattr room_map structexclude
attr ventilSeite expert 2_raw
attr ventilSeite model HM-LC-SW4-SM-2
attr ventilSeite peerIDs 00000000,
attr ventilSeite subType switch

attr ventilSeite webCmd ein:aus
attr ventilSeite eventMap on:ein off:aus
attr ventilSeite devStateIcon ein:sprinkler_icon@5ECD3C aus:sprinkler_icon@808080 .*:sprinkler_icon@F19A38

attr ventilSeite room BEWÄSSERUNG
attr ventilSeite group 02_Kreise
attr ventilSeite alias Seite



############### VENTIL: HINTEN1
define ventilHinten1 CUL_HM 003
attr ventilHinten1 userattr room_map structexclude
attr ventilHinten1 expert 2_raw
attr ventilHinten1 model HM-LC-SW4-SM-2
attr ventilHinten1 peerIDs 00000000,
attr ventilHinten1 subType switch

attr ventilHinten1 webCmd ein:aus
attr ventilHinten1 eventMap on:ein off:aus
attr ventilHinten1 devStateIcon ein:sprinkler_icon@5ECD3C aus:sprinkler_icon@808080 .*:sprinkler_icon@F19A38

attr ventilHinten1 room BEWÄSSERUNG
attr ventilHinten1 group 02_Kreise
attr ventilHinten1 alias hinten1



############### VENTIL: HINTEN2
define ventilHinten2 CUL_HM 004
attr ventilHinten2 userattr room_map structexclude
attr ventilHinten2 expert 2_raw
attr ventilHinten2 model HM-LC-SW4-SM-2
attr ventilHinten2 peerIDs 00000000,
attr ventilHinten2 subType switch

attr ventilHinten2 webCmd ein:aus
attr ventilHinten2 eventMap on:ein off:aus
attr ventilHinten2 devStateIcon ein:sprinkler_icon@5ECD3C aus:sprinkler_icon@808080 .*:sprinkler_icon@F19A38

attr ventilHinten2 room BEWÄSSERUNG
attr ventilHinten2 group 02_Kreise
attr ventilHinten2 alias hinten2



define n_Aktorx notify ventil.*:on set ventil.*:FILTER=NAME!=$NAME {(("$EVENT" eq 'on')?'off':'on')}
attr n_Aktorx disabledAfterTrigger 1






Auszug aus dem EventLog:

2020-12-06 16:37:07 CUL_HM SW4_2 commState: CMDs_pending
2020-12-06 16:37:07 CUL_HM SW4_2 CMDs_pending
2020-12-06 16:37:07 CUL_HM ventilSeite set_on noArg
2020-12-06 16:37:07 CUL_HM SW4_2 commState: CMDs_processing...
2020-12-06 16:37:07 CUL_HM ventilSeite trigLast: fhem:02
2020-12-06 16:37:07 CUL_HM SW4_2 commState: CMDs_done
2020-12-06 16:37:07 CUL_HM SW4_2 CMDs_done
2020-12-06 16:37:07 CUL_HM SW4_2 commState: CMDs_pending
2020-12-06 16:37:07 CUL_HM SW4_2 CMDs_pending
2020-12-06 16:37:07 CUL_HM ventilHinten1 set_off noArg
2020-12-06 16:37:07 CUL_HM SW4_2 commState: CMDs_processing...
2020-12-06 16:37:07 CUL_HM ventilHinten1 trigLast: fhem:02
2020-12-06 16:37:07 CUL_HM ventilHinten2 set_off noArg
2020-12-06 16:37:07 CUL_HM ventilVorne set_off noArg
2020-12-06 16:37:07 CUL_HM ventilSeite deviceMsg: ein (to 5B154A)
2020-12-06 16:37:07 CUL_HM ventilSeite level: 100
2020-12-06 16:37:07 CUL_HM ventilSeite pct: 100
2020-12-06 16:37:07 CUL_HM ventilSeite ein
2020-12-06 16:37:07 CUL_HM ventilSeite timedOn: aus
2020-12-06 16:37:07 CUL_HM SW4_2 commState: CMDs_processing...
2020-12-06 16:37:07 CUL_HM ventilHinten1 deviceMsg: aus (to 5B154A)
2020-12-06 16:37:07 CUL_HM ventilHinten1 level: 0
2020-12-06 16:37:07 CUL_HM ventilHinten1 pct: 0
2020-12-06 16:37:07 CUL_HM ventilHinten1 aus
2020-12-06 16:37:07 CUL_HM ventilHinten1 timedOn: aus
2020-12-06 16:37:07 CUL_HM ventilHinten2 trigLast: fhem:02
2020-12-06 16:37:08 CUL_HM SW4_2 commState: CMDs_processing...
2020-12-06 16:37:08 CUL_HM ventilHinten2 deviceMsg: aus (to 5B154A)
2020-12-06 16:37:08 CUL_HM ventilHinten2 level: 0
2020-12-06 16:37:08 CUL_HM ventilHinten2 pct: 0
2020-12-06 16:37:08 CUL_HM ventilHinten2 aus
2020-12-06 16:37:08 CUL_HM ventilHinten2 timedOn: aus
2020-12-06 16:37:08 CUL_HM ventilVorne trigLast: fhem:02
2020-12-06 16:37:08 CUL_HM SW4_2 commState: CMDs_done
2020-12-06 16:37:08 CUL_HM SW4_2 CMDs_done
2020-12-06 16:37:08 CUL_HM ventilVorne deviceMsg: aus (to 5B154A)
2020-12-06 16:37:08 CUL_HM ventilVorne level: 0
2020-12-06 16:37:08 CUL_HM ventilVorne pct: 0
2020-12-06 16:37:08 CUL_HM ventilVorne aus
2020-12-06 16:37:08 CUL_HM ventilVorne timedOn: aus
2020-12-06 16:37:15 HMUARTLGW HMLAN1 UNKNOWNCODE A0DE1A6103F17F22B86040601C800::-86:HMLAN1
2020-12-06 16:37:15 HMUARTLGW HMLAN1 UNKNOWNCODE A11E1A0022B86043F17F204996C5627795902::-71:HMLAN1
2020-12-06 16:37:15 HMUARTLGW HMLAN1 UNKNOWNCODE A19E1A6033F17F22B86047323E80F82F256E00962FF4332E38907::-86:HMLAN1
2020-12-06 16:37:15 HMUARTLGW HMLAN1 UNKNOWNCODE A0EE180022B86043F17F200668BE1BE::-71:HMLAN1


Moin,

habe jetzt eine Weile geschaut und drüber nachgedacht:

ZitatKlicke ich hingegen auf die Aktoren (webCmd) dauert der Schaltvorgang lange und es erscheint "Connection Lost"...
Nach 5 Sekunden fängt sich die Seite meist aber wieder.
Schön ist das aber nicht.

Ist das eine generelles Verhalten? Als bei allen HM Geräten so? Liegt das Verhalten ev. nicht an dieser Logik?

Im Eventlog sehe ich jetzt überhaupt keinen on Event mehr. Klar Du hast das mit EventMap umgemappt. Ich bin mir immer nicht 100% sicher was da passiert. Ich habe solche "Spielereien" mittlerweile alle wieder rausgenommen.

Also was ich sagen will: Laut deinem Eventlog dürfte das notify von "mir" gar  nicht anspringen. Trotzdem erfolgt ja die Schaltlogik wie gewünscht.
Kannst Du mal ein list n_Aktorx zeigen?

Gruß Otto

Hallo Otto,

Zitathabe jetzt eine Weile geschaut und drüber nachgedacht

Vielen Dank für deine Mühe!

ZitatIst das eine generelles Verhalten? Als bei allen HM Geräten so? Liegt das Verhalten ev. nicht an dieser Logik?

Nein, alles andere ist super schnell und stabil!
Ich habe auch nicht gerade wenig mit FHEM umgesetzt und nutze es schon seit ca. 4 Jahren.
Ständig kommt etwas hinzu und hin und wieder fliegt auch mal etwas raus oder
ich optimiere mal etwas. Programmierung und IT sind mir auch nicht völlig fremd.
Aber hier lege ich mir echt die Karten!
Alles andere, was ich so brauchte, habe ich mir immer (nahezu) selbstständig erarbeiten können.

ZitatIch habe solche "Spielereien" mittlerweile alle wieder rausgenommen.

Wie hast du das dann umgesetzt?
Oder gibt es einen Best Practise oder eine Art "Norm"?

ZitatKannst Du mal ein list n_Aktorx zeigen?

Internals:
   CFGFN      ./FHEM/006_bewaesserung.cfg
   DEF        ventil.*:on set ventil.*:FILTER=NAME!=$NAME {(("$EVENT" eq 'on')?'off':'on')}
   FUUID      5fcd719c-f33f-1ce0-277f-58b77c643561c172
   NAME       n_Aktorx
   NOTIFYDEV  ventil.*
   NR         861
   NTFY_ORDER 50-n_Aktorx
   REGEXP     ventil.*:on
   STATE      active
   TYPE       notify
   READINGS:
     2020-12-07 01:04:44   state           active
Attributes:
   disabledAfterTrigger 1

Hallo remo,

dein list bestätigt meine Vermutung. Fällt Dir was auf?
Internals:
   CFGFN     
   DEF        Aktor.:on set Aktor.:FILTER=NAME!=$NAME {(("$EVENT" eq 'on')?'off':'on')}
   FUUID      5fca8b8b-f33f-27f7-3d03-aca8726804c29a28
   NAME       n_Aktorx
   NOTIFYDEV  Aktor.
   NR         180891
   NTFY_ORDER 50-n_Aktorx
   REGEXP     Aktor.:on
   STATE      2020-12-04 20:22:02
   TRIGGERTIME 1607109722.86281
   TYPE       notify
   READINGS:
     2020-12-04 20:19:39   state           active
Attributes:
   disabledAfterTrigger 1
   room       Test
Bei Dir STATE      active - das bedeutet im Klartext: definiert und noch nie gelaufen. Also wer immer deine Logik abarbeitet, dieses notify hat nichts damit zu tun  :o

Ich verändert einfach die Events nicht mehr: on ist eben on und gut. Auch wenn das beim Rolladen oben bedeutet ;)

Gruß Otto

Zitatdieses notify hat nichts damit zu tun

Wie kann das kommen?!


Ich habe mir jetzt nochmal ein Testkonstrukt gebaut.
Ohne Aktoren, nur Dummys und über das Web mit der "Maus" geschaltet.

Code:
define Aktor1 dummy
define Aktor2 dummy
define Aktor3 dummy
define Aktor4 dummy
attr Aktor. room Test

attr Aktor1 webCmd ein:aus
attr Aktor1 eventMap on:ein off:aus
attr Aktor1 devStateIcon ein:sprinkler_icon@5ECD3C aus:sprinkler_icon@808080 .*:sprinkler_icon@F19A38

attr Aktor2 webCmd ein:aus
attr Aktor2 eventMap on:ein off:aus
attr Aktor2 devStateIcon ein:sprinkler_icon@5ECD3C aus:sprinkler_icon@808080 .*:sprinkler_icon@F19A38

attr Aktor3 webCmd ein:aus
attr Aktor3 eventMap on:ein off:aus
attr Aktor3 devStateIcon ein:sprinkler_icon@5ECD3C aus:sprinkler_icon@808080 .*:sprinkler_icon@F19A38

attr Aktor4 webCmd ein:aus
attr Aktor4 eventMap on:ein off:aus
attr Aktor4 devStateIcon ein:sprinkler_icon@5ECD3C aus:sprinkler_icon@808080 .*:sprinkler_icon@F19A38

define n_Aktory notify Aktor.:on set Aktor.:FILTER=NAME!=$NAME {(("$EVENT" eq 'on')?'off':'on')}
attr n_Aktory disabledAfterTrigger 1
attr n_Aktory room Test

EventLog:
2020-12-07 16:31:30 dummy Aktor1 aus
2020-12-07 16:31:30 dummy Aktor3 aus
2020-12-07 16:31:30 dummy Aktor4 aus
2020-12-07 16:31:30 dummy Aktor2 ein
2020-12-07 16:31:36 dummy Aktor1 aus
2020-12-07 16:31:36 dummy Aktor2 aus
2020-12-07 16:31:36 dummy Aktor4 aus
2020-12-07 16:31:36 dummy Aktor3 ein
2020-12-07 16:31:40 dummy Aktor1 aus
2020-12-07 16:31:40 dummy Aktor2 aus
2020-12-07 16:31:40 dummy Aktor3 aus
2020-12-07 16:31:40 dummy Aktor4 ein

list n_Aktory:
Internals:
   CFGFN      ./FHEM/006_bewaesserung.cfg
   DEF        Aktor.:on set Aktor.:FILTER=NAME!=$NAME {(("$EVENT" eq 'on')?'off':'on')}
   FUUID      5fce4aaa-f33f-1ce0-4e69-cdda64eff31f39bb
   NAME       n_Aktory
   NOTIFYDEV  Aktor.
   NR         882
   NTFY_ORDER 50-n_Aktory
   REGEXP     Aktor.:on
   STATE      2020-12-07 16:31:40
   TRIGGERTIME 1607355100.35103
   TYPE       notify
   READINGS:
     2020-12-07 16:30:50   state           active
Attributes:
   disabledAfterTrigger 1
   room       Test


Ergebnis:
Überwiegend "Connection Lost..." und keine Aktualisierung der Seite ... wie vorher also!
Ich vermute, dass das Notify das Problem verursacht.

Deinen Test kann ich 100% nachvollziehen - ist bei mir genau wie Du beschreibst - aber

Zitat von: remo am 07 Dezember 2020, 16:33:33
Ich vermute, dass das Notify das Problem verursacht.

Dann mach mal
deleteattr Aktor. devStateIcon

und versuch nochmal  ;D

Zitatund versuch nochmal

Gut, jetzt ist mein Sprinkler-Icon weg, die Farben auch, ABER ES FUNKTIONIERT!

"aktiviere" ich meine Icons und Farben wieder, ist das Verhalten wie zuvor ...

Wie kann das sein???

Tja es braucht offenbar Zeit die Sprenger Icons zu malen und bunt zu färben. Damit habe ich keine Erfahrung  :-[
Es sind definiv die Icons - Du kannst das notify deaktivieren, das Verhalten ist träge. Natürlich nicht so sichtbar wie bei 4 Icons gleichzeitig, das passiert ja bei dem Automatismus.
Ob man das optimieren kann weiß ich nicht.  Aber wir kennen jetzt die Ursache 

Wahnsinn!

Besten Dank für die forensische Arbeit - wirklich!

Vielleicht gibt es eine Möglichkeit, FHEM "überlegen" zu lassen bis alle Icons gemalt sind.
Ich hätte kein Problem damit, 3 Sekunden pro Aktion zu warten - die Bewässerung ist ja sowieso träge und alle 5 Sekunden Kreise umschalten
möchte ich ja auch nicht.

ZitatDamit habe ich keine Erfahrung

Wenn du keine devStateIcons verwendest, was dann?

Zitat"Tja es braucht offenbar Zeit die Sprenger Icons zu malen und bunt zu färben"
"Vielleicht gibt es eine Möglichkeit, FHEM "überlegen" zu lassen bis alle Icons gemalt sind."

Vielleicht hat der Herr König eine Meinung dazu?

Hallo,

habs auch mal bei mir nachgestellt, hört sich merkwürdig an , aber bei mir kommt das "Connection Lost..." nur in FHEMWEB im Raum Everything.
In der Detailansicht des Geräts und in der Raumansicht kommt die Meldung bei mir nicht.

So steht das bei mir in der fhem.cfg:

define Aktor1 dummy
setuuid Aktor1 5fce5294-f33f-c4a2-48f1-f9cdc521321fb1c3
attr Aktor1 devStateIcon ein:sprinkler_icon@5ECD3C aus:sprinkler_icon@808080 .*:sprinkler_icon@F19A38
attr Aktor1 eventMap on:ein off:aus
attr Aktor1 webCmd ein:aus
define Aktor2 dummy
setuuid Aktor2 5fce5294-f33f-c4a2-8b98-68263619c14532fc
attr Aktor2 devStateIcon ein:sprinkler_icon@5ECD3C aus:sprinkler_icon@808080 .*:sprinkler_icon@F19A38
attr Aktor2 eventMap on:ein off:aus
attr Aktor2 webCmd ein:aus
define Aktor3 dummy
setuuid Aktor3 5fce5294-f33f-c4a2-a36e-70dd8b3ac81faf5c
attr Aktor3 devStateIcon ein:sprinkler_icon@5ECD3C aus:sprinkler_icon@808080 .*:sprinkler_icon@F19A38
attr Aktor3 eventMap on:ein off:aus
attr Aktor3 webCmd ein:aus
define Aktor4 dummy
setuuid Aktor4 5fce5294-f33f-c4a2-0248-b9331d4ad3c83dd3
attr Aktor4 devStateIcon ein:sprinkler_icon@5ECD3C aus:sprinkler_icon@808080 .*:sprinkler_icon@F19A38
attr Aktor4 eventMap on:ein off:aus
attr Aktor4 webCmd ein:aus
define n_Aktory notify Aktor.:on set Aktor.:FILTER=NAME!=$NAME {(("$EVENT" eq 'on')?'off':'on')}
setuuid n_Aktory 5fce5294-f33f-c4a2-a1e2-a88a192ec0a9b961
attr n_Aktory disabledAfterTrigger 1
attr n_Aktory room Test

Weil ich nicht genau weiß was das für eine Ausgabe ist:

define Aktor1 dummy
define Aktor2 dummy
define Aktor3 dummy
define Aktor4 dummy
attr Aktor. room Test

attr Aktor1 webCmd ein:aus
attr Aktor1 eventMap on:ein off:aus
attr Aktor1 devStateIcon ein:sprinkler_icon@5ECD3C aus:sprinkler_icon@808080 .*:sprinkler_icon@F19A38

attr Aktor2 webCmd ein:aus
attr Aktor2 eventMap on:ein off:aus
attr Aktor2 devStateIcon ein:sprinkler_icon@5ECD3C aus:sprinkler_icon@808080 .*:sprinkler_icon@F19A38

attr Aktor3 webCmd ein:aus
attr Aktor3 eventMap on:ein off:aus
attr Aktor3 devStateIcon ein:sprinkler_icon@5ECD3C aus:sprinkler_icon@808080 .*:sprinkler_icon@F19A38

attr Aktor4 webCmd ein:aus
attr Aktor4 eventMap on:ein off:aus
attr Aktor4 devStateIcon ein:sprinkler_icon@5ECD3C aus:sprinkler_icon@808080 .*:sprinkler_icon@F19A38

define n_Aktory notify Aktor.:on set Aktor.:FILTER=NAME!=$NAME {(("$EVENT" eq 'on')?'off':'on')}
attr n_Aktory disabledAfterTrigger 1
attr n_Aktory room Test

Gruß

Thomas

Nochwas vergessen: das "Connection Lost..." kommt bei mir nur beim einschalten.

naja weil nur beim einschalten die Schleife über 4 Geräte gemacht wird :) eins merkt man nicht.
Ja man sieht es nur / connection lost / wenn man alle 4 Geräte im Überblick hat.
Die Standard Glühbirne reagiert schnell ;)

Das sind SVG Bildchen? vielleicht kann man SVG irgendwie optimieren - aber plotfork bringt es nicht.

Da mag was dran sein, 1-3 Aktoren in einem Raum und kein "Connection Lost...", kommt der vierte dazu kommt die Meldung.

Interessant ist bei mir: das scheint relativ unabhängig von der darunterliegenden Hardware zu sein. Passiert ziemlich identisch auf langsamen und schnelleren Maschinen. Aber beim PiB gehts praktisch gar nicht.
Auf schnelleren Maschinen kommt Connection lost schneller :)

Teste hier an einen RasPiZeroW  ;D

Wenn man das so schreibt:

Aktor.:on set Aktor(1-4):FILTER=NAME!=$NAME

oder auch so:
Aktor(1-4):on set Aktor(1-4):FILTER=NAME!=$NAME

hat man das Problem nicht.

aber da wird ja auch nichts geschaltet?  Aktor(1-4) ist doch kein gültiges devSpec?

Na dann siehste mal was ne halbe Flasche Bier so bewirkt  ;D, ich hab nur noch auf das "Connection Lost..." geachtet.

Jetzt hab ich eine neu Theorie (wegen dem guten Bier).

Wenn ich in jedem Aktor den Parameter zum schalten in devstateIcon mit angebe, kommt es nicht mehr zu der Meldung.

ein:sprinkler_icon@5ECD3C:aus aus:sprinkler_icon@808080:ein

In Firefox unter Web-Entwickler->Web-Konsole sehe ich die Meldung nicht mehr kommen, wenn ich auf eines der Icon klicke.


define Aktor1 dummy
setuuid Aktor1 5fce5294-f33f-c4a2-48f1-f9cdc521321fb1c3
attr Aktor1 devStateIcon ein:hue_filled_outlet@5ECD3C:aus aus:hue_filled_outlet@808080:ein
attr Aktor1 eventMap on:ein off:aus
attr Aktor1 room y
attr Aktor1 webCmd ein:aus
define Aktor2 dummy
setuuid Aktor2 5fce5294-f33f-c4a2-8b98-68263619c14532fc
attr Aktor2 devStateIcon ein:hue_filled_outlet@5ECD3C:aus aus:hue_filled_outlet@808080:ein
attr Aktor2 eventMap on:ein off:aus
attr Aktor2 room y
attr Aktor2 webCmd ein:aus
define Aktor3 dummy
setuuid Aktor3 5fce5294-f33f-c4a2-a36e-70dd8b3ac81faf5c
attr Aktor3 devStateIcon ein:hue_filled_outlet@5ECD3C:aus aus:hue_filled_outlet@808080:ein
attr Aktor3 eventMap on:ein off:aus
attr Aktor3 room y
attr Aktor3 webCmd ein:aus
define Aktor4 dummy
setuuid Aktor4 5fce5294-f33f-c4a2-0248-b9331d4ad3c83dd3
attr Aktor4 devStateIcon ein:hue_filled_outlet@5ECD3C:aus aus:hue_filled_outlet@808080:ein
attr Aktor4 eventMap on:ein off:aus
attr Aktor4 room y
attr Aktor4 webCmd ein:aus

define n_Aktory notify Aktor.:on set Aktor.:FILTER=NAME!=$NAME {(("$EVENT" eq 'on')?'off':'on')}
setuuid n_Aktory 5fce5294-f33f-c4a2-a1e2-a88a192ec0a9b961
attr n_Aktory disabledAfterTrigger 1
attr n_Aktory room Test

@TomLee:
Gute Idee. Teste ich nachher.
Was passiert bei dir, wenn du explizit ,,undefined" noch mit angibst statt .*:sprinkler... ?

Edit:

mit

attr Aktor.* devStateIcon ein:sprinkler_icon@5ECD3C aus:sprinkler_icon@808080 undefined:sprinkler_icon@F19A38
undefined:

Funktioniert es auch!

.*:sprinkler_icon@F19A38
.*:

scheint der Übeltäter zu sein!

Edit2:
Kommando zurück!
Geht nicht wenn undefined angegeben ist!

Ich meine es spricht nichts gegen .*:sprinkler_icon@F19A38

Habs bei mir zum nachvollziehen nur weggelassen, ich würde dann aber auch hier einen Befehl mit angeben der beim betätigen des Icons ausgeführt werden soll.
Wie ich es bisher verstanden habe dann vermutlich ein ?

.*:sprinkler_icon@F19A38:ein

Verstehe.

Dennoch, mit .* oder undefined -> "Connection lost"

ohne .* oder undefined -> weniger "Connection lost"

Um auf Nummer sicher zu gehen, weil bei mir klappt das jetzt einwandfrei, mit Kontrolle in der WEB-Konsole und du zeigst nicht was genau du definiert hast.

Lösch mal alle deine Aktoren und nimm meine Definitionen.

Über RAW-Definition oder dem + oben Links :

defmod Aktor1 dummy
attr Aktor1 devStateIcon ein:hue_filled_outlet@5ECD3C:aus aus:hue_filled_outlet@808080:ein .*:sprinkler_icon@F19A38:ein
attr Aktor1 eventMap on:ein off:aus
attr Aktor1 room y
attr Aktor1 webCmd ein:aus

defmod Aktor2 dummy
attr Aktor2 devStateIcon ein:hue_filled_outlet@5ECD3C:aus aus:hue_filled_outlet@808080:ein .*:sprinkler_icon@F19A38:ein
attr Aktor2 eventMap on:ein off:aus
attr Aktor2 room y
attr Aktor2 webCmd ein:aus

defmod Aktor3 dummy
attr Aktor3 devStateIcon ein:hue_filled_outlet@5ECD3C:aus aus:hue_filled_outlet@808080:ein .*:sprinkler_icon@F19A38:ein
attr Aktor3 eventMap on:ein off:aus
attr Aktor3 room y
attr Aktor3 webCmd ein:aus

defmod Aktor4 dummy
attr Aktor4 devStateIcon ein:hue_filled_outlet@5ECD3C:aus aus:hue_filled_outlet@808080:ein .*:sprinkler_icon@F19A38:ein
attr Aktor4 eventMap on:ein off:aus
attr Aktor4 room y
attr Aktor4 webCmd ein:aus


Dankeschön, aber Du hast den Notify vernachlässigt.
Ohne Notify hab ich auch keine Probleme.
Das Notify ist aber wichtig für mich.
Und mir Notify funktioniert es bei mir nur wirklich zuverlässig ohne devStateIcon.

An dem hab ich auch nichts geändert.

Dann nochmal mit notify, getestet, mehrfach:

defmod Aktor1 dummy
attr Aktor1 devStateIcon ein:hue_filled_outlet@5ECD3C:aus aus:hue_filled_outlet@808080:ein .*:sprinkler_icon@F19A38:ein
attr Aktor1 eventMap on:ein off:aus
attr Aktor1 room y
attr Aktor1 webCmd ein:aus

defmod Aktor2 dummy
attr Aktor2 devStateIcon ein:hue_filled_outlet@5ECD3C:aus aus:hue_filled_outlet@808080:ein .*:sprinkler_icon@F19A38:ein
attr Aktor2 eventMap on:ein off:aus
attr Aktor2 room y
attr Aktor2 webCmd ein:aus

defmod Aktor3 dummy
attr Aktor3 devStateIcon ein:hue_filled_outlet@5ECD3C:aus aus:hue_filled_outlet@808080:ein .*:sprinkler_icon@F19A38:ein
attr Aktor3 eventMap on:ein off:aus
attr Aktor3 room y
attr Aktor3 webCmd ein:aus

defmod Aktor4 dummy
attr Aktor4 devStateIcon ein:hue_filled_outlet@5ECD3C:aus aus:hue_filled_outlet@808080:ein .*:sprinkler_icon@F19A38:ein
attr Aktor4 eventMap on:ein off:aus
attr Aktor4 room y
attr Aktor4 webCmd ein:aus

defmod n_Aktory notify Aktor.:on set Aktor.:FILTER=NAME!=$NAME {(("$EVENT" eq 'on')?'off':'on')}
attr n_Aktory disabledAfterTrigger 1
attr n_Aktory room y


Gut, ok.
Das schaffe ich aber erst morgen.

Ich bedanke mich soweit bei euch und werde Rückmeldung geben.

Das Sprinkler Icon ist aber jetzt nutzlos? Das kann doch weg - oder ist das Kunst ;) ?
attr Aktor. devStateIcon ein:hue_filled_outlet@5ECD3C:aus aus:hue_filled_outlet@808080:ein

Wie meinst du das Otto?

Also klappts jetzt auch bei dir ?

Irgendwas hat remo ja vor, state kann offensichtlich auch einen anderen Status wie on/off haben.

edit:

hue_filled_outlet hab ich nur zum testen verwendet, um am Ende ausschliessen zu können das es am Icon selbst liegt.

Naja ich meine das Sprinkler Icon ist das Problem, wenn man das nicht mehr nimmt ist alles gut. In Tom seinem letzten Code spielt das beim Schalten keine Rolle mehr.
Aber das habe ich heute nachmittag auch schon gesagt  ;D

Tatsache mit dem Sprinkler-Icon kommts wieder zu der Meldung  ::), Gut Nacht.

Toll. Zufälle gibt's ... :D

Kann ich erst morgen testen.
Ich danke für eure Zeit.
Ihr lest von mir.

Gute Nacht.

Gut, es lag definitiv am Icon - Problem soweit gelöst.
Ich danke euch!

Der nächste Schritt ist ein on-for-timer ...
Ich habe schon getestet, aber leider nicht mit dem gewünschten Erfolg.

Meine Idee ist ein Notify:on-Ereignis auszulösen, indem ich ein

set sprengenVorne on-for-timer 10

absetze.

-> Das Icon springt auf grün, der Aktor schaltet.
Aber nach 10 Sekunden schaltet sich weder der Aktor ab, noch "erlischt" das Icon auf grau.

Das EventLog schreibt bloß ein on-for-timer-Ereignis, aber kein off nach Ablauf der Zeit.

Habe ich mal wieder einen Denkfehler?!


Edit:
ein dummy sprengenVorne off erscheint nach 10 Sekunden im EventLog (aber nicht immer), es passiert aber nix weiter (siehe oben).

Hast du den on-for-timer aktiviert in den Aktor-Devices ?

Bei mir klappts.

Stichwort:

useSetExtensions
   

Ich korrigiere:

ein 

set sprengenVorne on-for-timer 10

mach GAR NIX, außer das Icon zu färben.

Wenn ich also mit

set sprengenVorne on-for-timer 10

versuche ein Notify:on zu "provozieren" schaltet kein Aktor oder sonstwas.

Hier der komplette Code (auch wenn unübersichtlich und nicht optimal, das alte Problem ist gelöst und alles verhält sich so wie es soll, außer on-for-timer):

############### VENTIL: VORNE
define ventilVorne CUL_HM 001
attr ventilVorne userattr room_map structexclude
attr ventilVorne expert 2_raw
attr ventilVorne model HM-LC-SW4-SM-2
attr ventilVorne peerIDs 00000000,
attr ventilVorne subType switch

############### VENTIL: SEITE
define ventilSeite CUL_HM 002
attr ventilSeite userattr room_map structexclude
attr ventilSeite expert 2_raw
attr ventilSeite model HM-LC-SW4-SM-2
attr ventilSeite peerIDs 00000000,
attr ventilSeite subType switch

############### VENTIL: HINTEN1
define ventilHinten1 CUL_HM 003
attr ventilHinten1 userattr room_map structexclude
attr ventilHinten1 expert 2_raw
attr ventilHinten1 model HM-LC-SW4-SM-2
attr ventilHinten1 peerIDs 00000000,
attr ventilHinten1 subType switch

############### VENTIL: HINTEN2
define ventilHinten2 CUL_HM 004
attr ventilHinten2 userattr room_map structexclude
attr ventilHinten2 expert 2_raw
attr ventilHinten2 model HM-LC-SW4-SM-2
attr ventilHinten2 peerIDs 00000000,
attr ventilHinten2 subType switch

############### DUMMIES
define sprengenVorne dummy
attr sprengenVorne alias vorne
define sprengenSeite dummy
attr sprengenSeite alias Seite
define sprengenHinten1 dummy
attr sprengenHinten1 alias hinten1
define sprengenHinten2 dummy
attr sprengenHinten2 alias hinten2

############### WEB
attr sprengen.* webCmd ein:aus
attr sprengen.* eventMap ein:on aus:off
attr sprengen.* devStateIcon on:arch-linux@5ECD3C:on off:arch-linux@808080:off on-for-timer.*:arch-linux@5ECD3C:on .*:arch-linux@F19A38:off
attr sprengen.* room BEWÄSSERUNG
attr sprengen.* group 02_Kreise

############### NOTIFIES
define sprengenVorne_EIN notify sprengenVorne:on set ventilVorne on;; set sprengenHinten2 off;; set sprengenHinten1 off;; set sprengenSeite off;; set Laterne on;;
define sprengenVorne_AUS notify sprengenVorne:off set ventilVorne off;; set Pumpe off;; set Laterne off;;

define sprengenSeite_EIN notify sprengenSeite:on set ventilSeite on;; set sprengenHinten2 off;; set sprengenHinten1 off;; set sprengenVorne off;;
define sprengenSeite_AUS notify sprengenSeite:off set ventilSeite off;; set Pumpe off;;

define sprengenHinten1_EIN notify sprengenHinten1:on set ventilHinten1 on;; set sprengenHinten2 off;; set sprengenSeite off;; set sprengenVorne off;;
define sprengenHinten1_AUS notify sprengenHinten1:off set ventilHinten1 off;; set Pumpe off;;

define sprengenHinten2_EIN notify sprengenHinten2:on set ventilHinten2 on;; set sprengenHinten1 off;; set sprengenSeite off;; set sprengenVorne off;;
define sprengenHinten2_AUS notify sprengenHinten2:off set ventilHinten2 off;; set Pumpe off;;

############### SORT
attr sprengenVorne sortby 1
attr sprengenSeite sortby 2
attr sprengenHinten1 sortby 3
attr sprengenHinten2 sortby 4




### TEST

define sprengenVorne3_1 dummy

attr sprengenVorne3_1 webCmd ein
attr sprengenVorne3_1 devStateIcon ein:time_timer@367BF6:ein .*:time_timer@F19A38

define sprengenVorne3_2 notify sprengenVorne3_1:ein set sprengenVorne on-for-timer 10;;

attr sprengenVorne3_1 room BEWÄSSERUNG
attr sprengenVorne3_1 group 00_Schnellzugriffe
attr sprengenVorne3_1 alias vorne 10 Sek


set Laterne off

ist nur zum Testen, ob das SChalten eines unabhängigen Aktors funktioniert...

ZitatHast du den on-for-timer aktiviert in den Aktor-Devices ?

hilf mir mal bitte auf die Sprünge.

############### VENTIL: VORNE
define ventilVorne CUL_HM 001
attr ventilVorne userattr room_map structexclude
attr ventilVorne expert 2_raw
attr ventilVorne model HM-LC-SW4-SM-2
attr ventilVorne peerIDs 00000000,
attr ventilVorne subType switch

das fhem.log muss doch voll sein mit fehlermeldungen.

die def ist völlig falsch.
ein echtes channel device hat ausserdem kein attr subtype.
attr expert=2_raw gibt es auch schon länger nicht mehr.

bring dein system in ordnung.
=> "get hminfo configCheck" zeigt dann keine fehler.

Hmm...

Zitatein echtes channel device hat ausserdem kein attr subtype

Erschien nach dem Anlernen automatisch.

Zitatattr expert=2_raw gibt es auch schon länger nicht mehr.

Wusste ich nicht. Hatte keine Probleme damit und es analog zu meinen anderen Aktoren mit angegeben.

Zitatbring dein system in ordnung.

Ich habe bisher keinerlei Fehlverhalten festgestellt.
Alles ist zügig und zuverlässig.
Das seit mehreren Jahren.
Wenn du empfielst, ich solle mir das mal genauer ansehen, dann mache ich das selbstverständlich,
hatte bisher aber keinen Anlass / keine Indizien dazu.

Zitatget hminfo configCheck

Zeigt mir eine leere MessageBox ...

Zitat von: remo am 08 Dezember 2020, 13:58:00
Der nächste Schritt ist ein on-for-timer ...
Ich habe schon getestet, aber leider nicht mit dem gewünschten Erfolg.

@remo Du erinnerst Dich?
https://forum.fhem.de/index.php/topic,116443.msg1107930/topicseen.html#msg1107930

Also Du willst ein Ventil per Zeit (on-for-timer) steuern und parallel soll irgendwas anderes "mitlaufen"?

Du redest bei Deinen Versuchen vom Dummy oder von den echten Aktoren?

ZitatAlso Du willst ein Ventil per Zeit (on-for-timer) steuern und parallel soll irgendwas anderes "mitlaufen"?

Korrekt.

ZitatDu redest bei Deinen Versuchen vom Dummy oder von den echten Aktoren?

vom Dummy.

attr Aktor. setList on off
attr Aktor. useSetExtensions 1


Sonst gibt es kein on-for-timer  ::)

Aber es wird nicht gehen, weil die Dummys nicht die gleichen Events liefern wie die HM Aktoren!

dafür war meine Idee in etwa so:
define n_Aktorx2 notify ventil.*:timedOn:.* {if ($EVTPART1 eq "running") {fhem("set pumpe on")}else{fhem("set pumpe off")}}

Otto,

gut, das habe ich verstanden.

define n_ventil notify ventil.*:on set ventil.*:FILTER=NAME!=$NAME {(("$EVENT" eq 'on')?'off':'on')}

Habe ich denn darüber die Möglichkeit ein z.B. set Pumpe on mitzugeben?
Also mit dem Ziel, wenn Ventil on, dann auch Pumpe on - sonst umgekehrt ...

Zunächst mal: Du hast die unnötig komplizierte Version meines Vorschlages gewählt, das hier reicht völlig:
define n_ventil notify ventil.*:on set ventil.*:FILTER=NAME!=$NAME off
Und klar kannst Du set Pumpe on mitgeben:
define n_ventil notify ventil.*:on set ventil.*:FILTER=NAME!=$NAME off;;set Pumpe on

Aber das musst Du noch machen:

ZitatAlso mit dem Ziel, wenn Ventil on, dann auch Pumpe on - sonst umgekehrt ...

Mein Vorschlag aus #61 ist Mist?

define n_ventil notify ventil.*:on set ventil.*:FILTER=NAME!=$NAME off;;set Pumpe on
Funktioniert.

Aber das musst Du noch machen
Hab mir gerade ne tolle Schleife gebastelt  ???
...mache ich mir morgen Gedanken drüber.

ZitatMein Vorschlag aus #61 ist Mist?

Ist er nicht.
Aber: Der Aktor (Ventil) bleibt für Zeit X eingeschaltet, nach dem Abschalten färbt sich auch das Icon wieder zurück - gut soweit;
nur die Pumpe (hab ich zum Testen durch Laterne ersetzt) schaltet nicht nach Zeit X wieder ab, sondern sofort;
also kurz ein, dann sofort wieder aus.

Eventmonitor Auszug mit Filter ventil.* ?

Gerne

2020-12-08 21:25:29 CUL_HM ventilVorne set_on-for-timer 10
2020-12-08 21:25:29 CUL_HM ventilVorne trigLast: fhem:02
2020-12-08 21:25:29 CUL_HM ventilHinten1 set_off noArg
2020-12-08 21:25:29 CUL_HM ventilHinten1 trigLast: fhem:02
2020-12-08 21:25:29 CUL_HM ventilHinten2 set_off noArg
2020-12-08 21:25:29 CUL_HM ventilSeite set_off noArg
2020-12-08 21:25:29 CUL_HM ventilVorne deviceMsg: ein (to 5B154A)
2020-12-08 21:25:29 CUL_HM ventilVorne level: 100
2020-12-08 21:25:29 CUL_HM ventilVorne pct: 100
2020-12-08 21:25:29 CUL_HM ventilVorne ein
2020-12-08 21:25:29 CUL_HM ventilVorne timedOn: running
2020-12-08 21:25:30 CUL_HM ventilHinten1 deviceMsg: aus (to 5B154A)
2020-12-08 21:25:30 CUL_HM ventilHinten1 level: 0
2020-12-08 21:25:30 CUL_HM ventilHinten1 pct: 0
2020-12-08 21:25:30 CUL_HM ventilHinten1 aus
2020-12-08 21:25:30 CUL_HM ventilHinten1 timedOn: aus
2020-12-08 21:25:30 CUL_HM ventilHinten2 trigLast: fhem:02
2020-12-08 21:25:30 CUL_HM ventilHinten2 deviceMsg: aus (to 5B154A)
2020-12-08 21:25:30 CUL_HM ventilHinten2 level: 0
2020-12-08 21:25:30 CUL_HM ventilHinten2 pct: 0
2020-12-08 21:25:30 CUL_HM ventilHinten2 aus
2020-12-08 21:25:30 CUL_HM ventilHinten2 timedOn: aus
2020-12-08 21:25:30 CUL_HM ventilSeite trigLast: fhem:02
2020-12-08 21:25:31 CUL_HM ventilSeite deviceMsg: aus (to 5B154A)
2020-12-08 21:25:31 CUL_HM ventilSeite level: 0
2020-12-08 21:25:31 CUL_HM ventilSeite pct: 0
2020-12-08 21:25:31 CUL_HM ventilSeite aus
2020-12-08 21:25:31 CUL_HM ventilSeite timedOn: aus
2020-12-08 21:25:41 CUL_HM ventilVorne deviceMsg: aus (to 5B154A)
2020-12-08 21:25:41 CUL_HM ventilVorne level: 0
2020-12-08 21:25:41 CUL_HM ventilVorne pct: 0
2020-12-08 21:25:41 CUL_HM ventilVorne aus
2020-12-08 21:25:41 CUL_HM ventilVorne timedOn: aus

Naja klar:
2020-12-08 21:25:29 CUL_HM ventilVorne timedOn: running
...
2020-12-08 21:25:30 CUL_HM ventilHinten1 timedOn: aus

Mist :(

Man könnte ein dünnes Brett bohren und sagen:
disableAfterTrigger 10

???

Ach... Klar!
Das off wird mitgesendet; soll ja auch, weil wenn ein Ventil on geht, sollen die anderen ja off gehen.
Somit geht immer irgendeins off und die Laterne/Pumpe ebenfalls ...

ich habe in der letzten Antwort nachgedacht :)

ZitatMan könnte ein dünnes Brett bohren und sagen
disableAfterTrigger 10

Dann müsste doch disableAfterTrigger aber auf den gleichen Wert wie on-for-Timer gesetzt werden?!

Mensch, ich bin doch nicht der Einzige, der ne Bewässerung automatisieren möchte ...
Sind meine Vorstellungen zu pervers oder gibt es bessere Ansätze und ich habe mir aus Versehen den schlechtesten ausgesucht ... ?!

Zitat von: remo am 08 Dezember 2020, 21:34:12
Dann müsste doch disableAfterTrigger aber auf den gleichen Wert wie on-for-Timer gesetzt werden?!

Denkst Du? Nein ich denke nicht, es wird ja der Eine ein und die anderen sofort aus geschaltet. Also Du musst nur ein paar Sekunden deaktivieren.

Jede Bewässerung ist anders :)  ;D ;D ;D

Zitat von: remo am 08 Dezember 2020, 21:36:10
und ich habe mir aus Versehen den schlechtesten ausgesucht ... ?!

Nein Du hattest einen Ansatz und hast Einen gefunden der schräg mitdenkt  8)
Und mit der Bewässerung haben wir doch noch Zeit bis zum Frühjahr? ;D ;D ;D

mit attr n_ventile disabledAfterTrigger 10 oder 5 oder 15
geht's leider auch nicht.


2020-12-08 21:57:11 CUL_HM ventilVorne set_on-for-timer 10
2020-12-08 21:57:11 CUL_HM ventilVorne trigLast: fhem:02
2020-12-08 21:57:11 CUL_HM ventilHinten1 set_off noArg
2020-12-08 21:57:11 CUL_HM ventilHinten1 trigLast: fhem:02
2020-12-08 21:57:11 CUL_HM ventilHinten2 set_off noArg
2020-12-08 21:57:12 CUL_HM ventilSeite set_off noArg
2020-12-08 21:57:12 CUL_HM ventilVorne deviceMsg: ein (to 5B154A)
2020-12-08 21:57:12 CUL_HM ventilVorne level: 100
2020-12-08 21:57:12 CUL_HM ventilVorne pct: 100
2020-12-08 21:57:12 CUL_HM ventilVorne ein
2020-12-08 21:57:12 CUL_HM ventilVorne timedOn: running
2020-12-08 21:57:12 CUL_HM ventilHinten1 deviceMsg: aus (to 5B154A)
2020-12-08 21:57:12 CUL_HM ventilHinten1 level: 0
2020-12-08 21:57:12 CUL_HM ventilHinten1 pct: 0
2020-12-08 21:57:12 CUL_HM ventilHinten1 aus
2020-12-08 21:57:12 CUL_HM ventilHinten1 timedOn: aus
2020-12-08 21:57:12 CUL_HM ventilHinten2 trigLast: fhem:02
2020-12-08 21:57:13 CUL_HM ventilHinten2 deviceMsg: aus (to 5B154A)
2020-12-08 21:57:13 CUL_HM ventilHinten2 level: 0
2020-12-08 21:57:13 CUL_HM ventilHinten2 pct: 0
2020-12-08 21:57:13 CUL_HM ventilHinten2 aus
2020-12-08 21:57:13 CUL_HM ventilHinten2 timedOn: aus
2020-12-08 21:57:13 CUL_HM ventilSeite trigLast: fhem:02
2020-12-08 21:57:13 CUL_HM ventilSeite deviceMsg: aus (to 5B154A)
2020-12-08 21:57:13 CUL_HM ventilSeite level: 0
2020-12-08 21:57:13 CUL_HM ventilSeite pct: 0
2020-12-08 21:57:13 CUL_HM ventilSeite aus
2020-12-08 21:57:13 CUL_HM ventilSeite timedOn: aus
2020-12-08 21:57:24 CUL_HM ventilVorne deviceMsg: aus (to 5B154A)
2020-12-08 21:57:24 CUL_HM ventilVorne level: 0
2020-12-08 21:57:24 CUL_HM ventilVorne pct: 0
2020-12-08 21:57:24 CUL_HM ventilVorne aus
2020-12-08 21:57:24 CUL_HM ventilVorne timedOn: aus


ZitatNein Du hattest einen Ansatz und hast Einen gefunden der schräg mitdenkt

:D

ZitatUnd mit der Bewässerung haben wir doch noch Zeit bis zum Frühjahr? ;D ;D ;D

Stimmt ...



Ich muss jetzt erstmal ins Bett.
Morgen ist ein neuer Tag!
So allmählich nähern wir uns ja ...



Zwischendurch nochmals: Vielen Dank für deine Geduld!

Aber Du hast jetzt kurze Zeiten gewählt:
2020-12-08 21:57:12 CUL_HM ventilVorne timedOn: running
2020-12-08 21:57:12 CUL_HM ventilHinten1 timedOn: aus
2020-12-08 21:57:13 CUL_HM ventilHinten2 timedOn: aus
2020-12-08 21:57:13 CUL_HM ventilSeite timedOn: aus
2020-12-08 21:57:24 CUL_HM ventilVorne timedOn: aus


Gute Nacht :)

Genau. Zum Testen. Weil ich nicht jedes Mal 5 Minuten warten möchte, um zu sehen, ob es funktioniert. Keine gute Idee?

naja ich meine 5 sec disable würde reichen? Dann müsste doch die Pumpe erst am Ende des on-for-timer ausschalten?

Denn das notify macht ja beides, es schaltet die Pumpe ein und beim letzten wieder aus!
define n_Aktorx2 notify ventil.*:timedOn:.* {if ($EVTPART1 eq "running") {fhem("set pumpe on")}else{fhem("set pumpe off")}}
attr n_Aktorx2 disableAfterTrigger 5

So, ganz stranges Verhalten:

mit on-for-timer 30 und
disableAfterTrigger 5

Bleiben das Ventil und die Pumpe (Laterne zum Testen) 30 Sekunden ein und gehen dann auch beide wieder aus --- check!

Aber :D

Wenn ich die Ventile nun manuell über das Web schalte (immer nur eins ein, die anderen dann aus; ohne on-for-timer), schaltet sich die Laterne für einen kurzen Moment (1 Sekunden) mit ein...  :o

Moin,

ok dagegen hätte ich eventuell was:
attr ventil.* event-on-change-reading .*

Du kannst im Eventmonitor wieder schön sehen warum es passiert:
Ohne eocr
2020-12-09 09:56:08 CUL_HM SD3 commState: CMDs_pending
2020-12-09 09:56:08 CUL_HM SD3 set_on
2020-12-09 09:56:09 CUL_HM SD3 commState: CMDs_done
2020-12-09 09:56:09 CUL_HM SD3 deviceMsg: on (to VCCU)
2020-12-09 09:56:09 CUL_HM SD3 level: 100
2020-12-09 09:56:09 CUL_HM SD3 pct: 100
2020-12-09 09:56:09 CUL_HM SD3 on
2020-12-09 09:56:09 CUL_HM SD3 timedOn: off
mit eocr
2020-12-09 09:54:49 CUL_HM SD3 commState: CMDs_pending
2020-12-09 09:54:49 CUL_HM SD3 set_on
2020-12-09 09:54:49 CUL_HM SD3 commState: CMDs_done
2020-12-09 09:54:49 CUL_HM SD3 deviceMsg: on (to VCCU)
2020-12-09 09:54:49 CUL_HM SD3 level: 100
2020-12-09 09:54:49 CUL_HM SD3 pct: 100
2020-12-09 09:54:49 CUL_HM SD3 on
Wobei mein letztes notify ja auf den running event reagiert. Oder hast Du in dem anderen notify zusätzlich noch set Pumpe on drin?

Moin Otto, gut geschlafen? :D

mit
attr ventil.* event-on-change-reading .*
sieht on-for-timer nun gut aus.

Allerdings kann ich jetzt zwei Ventile einschalten.
Also es schaltet sich nicht immer das vorhergehende Ventil ab, wenn ich ein anderes einschalte ...

ZitatWobei mein letztes notify ja auf den running event reagiert. Oder hast Du in dem anderen notify zusätzlich noch set Pumpe on drin?

define n_ventile notify ventil.*:on set ventil.*:FILTER=NAME!=$NAME off;; set Laterne on;;
define n_Aktorx2 notify ventil.*:timedOn:.* {if ($EVTPART1 eq "running") {fhem("set Laterne on")}else{fhem("set Laterne off")}}

ZitatAllerdings kann ich jetzt zwei Ventile einschalten.
Also es schaltet sich nicht immer das vorhergehende Ventil ab, wenn ich ein anderes einschalte ...

Das kann ich umgehen, indem ich
attr n_ventile disabledAfterTrigger 5
Sekunden mit dem nächsten manuellen Schaltvorgang warte...

EDIT:

attr n_ventile disabledAfterTrigger 1
reicht scheinbar aus, wenn das on-for-timer > 5 ist.
In der Praxis wird es sich später sowieso um einen längeren Zeitraum handeln.

Zum Stand:
- Manuelles Schalten der Ventile zzgl. Pumpe/Laterne (immer nur eine Ventil ein, aber Pumpe/Laterne mit einschalten) funktioniert.   ---   check!
- on-for-timer > 5 funktioniert (auch wenn zuvor schon ein Ventil ein war); Ventil + Pumpe/Laterne schalten nach Zeit X ab und das Web aktualisiert sich auch.   ----   check!

So, letzte Baustelle:
Pumpe/Laterne aus, wenn Ventil manuell aus

define n_ventile notify ventil.*:on set ventil.*:FILTER=NAME!=$NAME off;; set Laterne on;;

wenn man dort noch irgendwie "clever" set Laterne <ventil.state> einbauen könnte...  ???


EDIT 2:
Otto, es sieht wirklich gut aus bisher...
Meine Tests liefen wirklich gut bis jetzt!

So, letzte Baustelle:
Pumpe/Laterne aus, wenn Ventil manuell aus

Code: [Auswählen]
define n_ventile notify ventil.*:on set ventil.*:FILTER=NAME!=$NAME off;; set Laterne on;;

wenn man dort noch irgendwie "clever" set Laterne <ventil.state> einbauen könnte

Hast du vielleicht noch einen heissen tipp für mich?

Also doch beide Events abfangen
on -> alle Ventile außer das gerade geschaltete off, Pumpe on
off -> Pumpe off
?

Zitaton -> alle Ventile außer das gerade geschaltete off, Pumpe on

genau. Funktioniert ja schon.

Zitatoff -> Pumpe off

genau. Ventil wieder manuell aus, also auch Pumpe aus.

Ist das realistisch?

defmod n_ventile notify ventil.*:on|ventil.*:off set ventil.*:FILTER=NAME!=$NAME off;; set Laterne $EVENT
Eigentlich ist es doch bei dem notify egal ob die anderen Ventile auch off bekommen wenn die Pumpe aus geht?

Gruß Otto

ZitatEigentlich ist es doch bei dem notify egal ob die anderen Ventile auch off bekommen wenn die Pumpe aus geht?

Ich glaube wir haben uns missverstanden?!

IST-Zustand: ich schalte ein Ventil ein oder auf ein anderes um (egal welches), die anderen schalten ab, es schaltet sich die Pumpe/Laterne mit ein.   ---   check!
SOLL: ich schalte besagtes Ventil wieder aus (sodass alle Ventile ausgeschaltet sind), die Pumpe/Laterne schaltet sich ebenfalls mit aus.

EDIT:
So langsam macht mich die ganze Sache mürbe ...  :-\
Wir können auch gerne mal ein zwei Tage Pause machen :D

Zitat von: remo am 09 Dezember 2020, 21:03:16
Ich glaube wir haben uns missverstanden?!

Ich glaube nicht :)

Was sollte das notify (die Modifikation oben) machen?
Es reagiert nicht nur auf den Befehl "ventil on" sondern auch auf "ventil off"

Bei ventil1 on passiert exakt das wie bisher: ventil 2-4 gehen off die Pumpe geht on.
Alles läuft sagen wir 10 min ...
Bei ventil1 off bekommen die ventile 2-4 auch wieder off, ist egal die sind off, aber die Pumpe bekommt auch ein off.

Das wolltest Du doch? Die Zeitsteuerung ist davon nicht betroffen.

wenn ich
define n_ventile notify ventil.*:on set ventil.*:FILTER=NAME!=$NAME off;; set Latern on;;
durch
defmod n_ventile notify ventil.*:on|ventil.*:off set ventil.*:FILTER=NAME!=$NAME off;; set Laterne $EVENT
ersetze, blinken meine Ventil-Aktoren wie Weihnachtsbeleuchtung orange (undefined) ...

machst Du mal bitte sicherheitshalber ein list n_ventile ?
Und schneidest mal ein on und ein off im Evntmonitor mit? ventil.*

Aber ich will Dich nicht stressen :)

Du stresst mich doch nicht!
Ich hoffe ich mache nicht den Eindruck!
Ich bin dir sehr dankbar! Wirklich!

Mache ich gerne, aber das schaffe ich leider erst morgen.
Meine Kinder wissen schon nicht mehr wie ich aussehe :D
Man beißt sich gerne zu sehr an solchen Problemen fest, aber jetzt muss ich erstmal meinen väterlichen Pflichten nachkommen ;)

Guten Morgen ;)

Zitatmachst Du mal bitte sicherheitshalber ein list n_ventile ?


Internals:
   CFGFN      ./FHEM/006_bewaesserung.cfg
   DEF        ventil.*:on|ventil.*:off set ventil.*:FILTER=NAME!=$NAME off; set Terrasse $EVENT
   FUUID      5fd1c5e2-f33f-1ce0-9519-c872e497dafd4205
   NAME       n_ventile
   NOTIFYDEV  ventil.*
   NR         873
   NTFY_ORDER 50-n_ventile
   REGEXP     ventil.*:on|ventil.*:off
   STATE      active
   TYPE       notify
   READINGS:
     2020-12-10 07:53:22   state           active
Attributes:
   disabledAfterTrigger 1



Und schneidest mal ein on und ein off im Evntmonitor mit? ventil.*

2020-12-10 07:54:14 CUL_HM ventilVorne set_on noArg
2020-12-10 07:54:14 CUL_HM ventilHinten1 set_off noArg
2020-12-10 07:54:14 CUL_HM ventilHinten2 set_off noArg
2020-12-10 07:54:14 CUL_HM ventilSeite set_off noArg
2020-12-10 07:54:14 CUL_HM ventilVorne deviceMsg: ein (to 5B154A)
2020-12-10 07:54:14 CUL_HM ventilVorne level: 100
2020-12-10 07:54:14 CUL_HM ventilVorne pct: 100
2020-12-10 07:54:14 CUL_HM ventilVorne ein
2020-12-10 07:54:14 CUL_HM ventilHinten1 aus
2020-12-10 07:54:15 CUL_HM ventilHinten2 aus
2020-12-10 07:54:15 CUL_HM ventilHinten1 set_off noArg
2020-12-10 07:54:15 CUL_HM ventilHinten2 set_off noArg
2020-12-10 07:54:15 CUL_HM ventilVorne set_off noArg
2020-12-10 07:54:15 CUL_HM ventilSeite aus
2020-12-10 07:54:15 CUL_HM ventilHinten1 aus
2020-12-10 07:54:16 CUL_HM ventilHinten2 aus
2020-12-10 07:54:16 CUL_HM ventilHinten1 set_off noArg
2020-12-10 07:54:16 CUL_HM ventilHinten2 set_off noArg
2020-12-10 07:54:16 CUL_HM ventilSeite set_off noArg
2020-12-10 07:54:16 CUL_HM ventilVorne deviceMsg: aus (to 5B154A)
2020-12-10 07:54:16 CUL_HM ventilVorne level: 0
2020-12-10 07:54:16 CUL_HM ventilVorne pct: 0
2020-12-10 07:54:16 CUL_HM ventilVorne aus
2020-12-10 07:54:17 CUL_HM ventilHinten1 aus
2020-12-10 07:54:17 CUL_HM ventilHinten2 aus
2020-12-10 07:54:17 CUL_HM ventilHinten1 set_off noArg
2020-12-10 07:54:17 CUL_HM ventilHinten2 set_off noArg
2020-12-10 07:54:17 CUL_HM ventilVorne set_off noArg
2020-12-10 07:54:17 CUL_HM ventilSeite aus
2020-12-10 07:54:18 CUL_HM ventilHinten1 aus
2020-12-10 07:54:18 CUL_HM ventilHinten2 aus
2020-12-10 07:54:18 CUL_HM ventilHinten1 set_off noArg
2020-12-10 07:54:18 CUL_HM ventilHinten2 set_off noArg
2020-12-10 07:54:18 CUL_HM ventilSeite set_off noArg
2020-12-10 07:54:18 CUL_HM ventilVorne aus
2020-12-10 07:54:19 CUL_HM ventilHinten1 aus
2020-12-10 07:54:19 CUL_HM ventilHinten2 aus
2020-12-10 07:54:19 CUL_HM ventilHinten1 set_off noArg
2020-12-10 07:54:19 CUL_HM ventilHinten2 set_off noArg
2020-12-10 07:54:19 CUL_HM ventilVorne set_off noArg
2020-12-10 07:54:19 CUL_HM ventilSeite aus
2020-12-10 07:54:20 CUL_HM ventilHinten1 aus
2020-12-10 07:54:20 CUL_HM ventilHinten2 aus
2020-12-10 07:54:21 CUL_HM ventilHinten1 set_off noArg
2020-12-10 07:54:21 CUL_HM ventilHinten2 set_off noArg
2020-12-10 07:54:21 CUL_HM ventilSeite set_off noArg
2020-12-10 07:54:21 CUL_HM ventilVorne aus
2020-12-10 07:54:21 CUL_HM ventilHinten1 aus
2020-12-10 07:54:21 CUL_HM ventilHinten2 aus
2020-12-10 07:54:22 CUL_HM ventilHinten1 set_off noArg
2020-12-10 07:54:22 CUL_HM ventilHinten2 set_off noArg
2020-12-10 07:54:22 CUL_HM ventilVorne set_off noArg


und so geht's endlos weiter ...

Ich bin noch mal in mich gegangen und habe über das gesamte Konstrukt nachgedacht,
bzw. ein paar reale Szenarien "simuliert":

Ich brauche es gar nicht so kompliziert.
Eine Verknüpfung von Ventil und Pumpe in allen erdenklichen Situationen ist gar nicht unbedingt notwendig.

Ich teste mal weiter und melde mich wieder ...

Schöne Mittagspause :)

das ist zu knapp:
disabledAfterTrigger 1

Sieht man doch ganz gut: Das letzte Ventil meldet erst nach einer Sekunde

Zitat2020-12-10 07:54:14 CUL_HM ventilHinten1 aus
2020-12-10 07:54:15 CUL_HM ventilHinten2 aus
2020-12-10 07:54:15 CUL_HM ventilHinten1 set_off noArg

Danach wird es eine Schleife. Also mindestens
disabledAfterTrigger 2 besser 3 oder 4!

eventuell kann man auch die antwortzeiten beim aktor reduzieren.
register: statusInfoMinDly und statusInfoRandom

So Freunde,
ich habe jetzt alles was ich brauche!

Super.

Nochmals: vielen herzlichen Dank an die Helfer, vorallem an Otto  :-*

Wenn Du jetzt lieb zum Forum sein willst:
Schreibst Du es nochmal zusammenfassend auf
Editierst Deine ersten Beitrag im Betreff und schreibst gelöst hin. 8)

In meinem Adventskalender waren heute 3 sprinkler-Icons (png,je 3,5kB), eventuell passen die ja bei manchen ins Farbschema für die hier gefundene Lösung

TomLee :)

Wo gibt es solche Adventskalender? ^^

Ich danke aufrichtig und wünsche euch allen eine schöne Weihnachtszeit!

@Otto:
Wenn ich das nächste Mal in Leipzig bin, trinken wir ein Bierchen (oder Kaffe, oder Tee) ;)

remo oder auch Otto,

wollt ihr mal das hier (https://forum.fhem.de/index.php/topic,117494.msg1119011.html#msg1119011) angehangene sprinkler-SVG-Icon testen ?

Bin der Meinung damit klappt das jetzt.

define Aktor1 dummy
attr Aktor1 devStateIcon ein:sprinkler_icon@5ECD3C aus:sprinkler_icon@808080 .*:sprinkler_icon@F19A38
attr Aktor1 eventMap on:ein off:aus
attr Aktor1 webCmd ein:aus
attr Aktor1 room Test
attr Aktor1 group Test
define Aktor2 dummy
attr Aktor2 devStateIcon ein:sprinkler_icon@5ECD3C aus:sprinkler_icon@808080 .*:sprinkler_icon@F19A38
attr Aktor2 eventMap on:ein off:aus
attr Aktor2 webCmd ein:aus
attr Aktor2 room Test
attr Aktor2 group Test
define Aktor3 dummy
attr Aktor3 devStateIcon ein:sprinkler_icon@5ECD3C aus:sprinkler_icon@808080 .*:sprinkler_icon@F19A38
attr Aktor3 eventMap on:ein off:aus
attr Aktor3 webCmd ein:aus
attr Aktor3 room Test
attr Aktor3 group Test
define Aktor4 dummy
attr Aktor4 devStateIcon ein:sprinkler_icon@5ECD3C aus:sprinkler_icon@808080 .*:sprinkler_icon@F19A38
attr Aktor4 eventMap on:ein off:aus
attr Aktor4 webCmd ein:aus
attr Aktor4 room Test
attr Aktor4 group Test
define n_Aktory notify Aktor.:on set Aktor.:FILTER=NAME!=$NAME {(("$EVENT" eq 'on')?'off':'on')}
attr n_Aktory disabledAfterTrigger 1
attr n_Aktory room Test
attr n_Aktory group Test

Zitatremo oder auch Otto,

wollt ihr mal das hier angehangene sprinkler-SVG-Icon testen ?

Oder einer der anderen 5 die das Icon bereits runtergeladen und das getestet haben Rückmeldung geben ?

Hallo zusammen und schöne Ostern,
@TomLee:
ja, sieht gut aus.
Setze ich bereits ein.
Vielen Dank.

Ich habe mich jetzt eine Weile nicht gemeldet.
Inzwischen habe ich einen guten Stand was meine Bewässerung angeht.
Jetzt würde ich gerne noch FHEM diesbezüglich fit machen.

Meine Idee ist, einen Bewässerungsplan in FHEM abzubilden.
Dazu habe ich mal eine Skizze angehängt.

Bevor ich mich in einem Ansatz verrenne, möchte ich euch freundlich bitten, mir mitzuteilen, ob das so überhaupt funktionieren kann?!
Meine Zeit ist sehr knapp bemessen. Im Moment bin ich zeitlich sehr stark eingespannt.

Guckt euch meine Skizze einfach mal an wenn ihr Lust und Zeit habt.
Die auf der Skizze abgebildete Logik ist zu vernachlässigen - es geht rein um die Darstellung.
Vielleicht habt ihr ja einen Anreiz für mich?!

Ganz liebe Grüße.
Remo

Edit:
Dass das vielleicht nur mit massenhaft Dummys und if-Anweisungen verbunden sein wird ist mir bewusst. Das bekomme ich aber, denke ich hin. Meine Rollladensteuerung ist ebenfalls sehr komplex und ein guter Anfang. Darauf kann ich aufbauen.
Ich würde nur gerne diese Ansicht umsetzten. Mit uA Eingabefeldern (Uhrzeit (at) + Laufzeit (on-for-timer)).

Ich würde vielleicht für jede mögliche Eingabe (Startzeit, Laufzeit, Wochentag) einen Dummy definieren und über das Web dann gezielt die Dummys setzen. Und im at würde ich dann eine komplexe if-Abfrage definieren.   

Hallo und einen guten Start in eine verkürzte Woche wünsche ich euch.

Ich hatte etwas Zeit, um mich weiter um meine Bewässeungssteuerung zu kümmern.
Ich habe damit angefangen, die Skizze aus meinem letzten Post umzusetzen.

Jetzt beiße ich mir aber leider seit ein paar Stunden die Zähne aus.

Exemplarisch:

defmod du11 dummy

attr du11 readingList aktiv1 mon1 tue1
attr du11 setList aktiv1:on,off mon1:on,off tue1:on,off

attr du11 webCmd aktiv1:mon1:tue1
attr du11 webCmdLabel aktiviert:Mo:Di

# problem
#attr du11 devStateIcon on:ios_on_fill off:ios_off_fill

attr du11 room TEST2


Erzeugt folgende Ansicht: siehe Anhang

Ich hätte aber gerne, so wie man das auch sonst bei einem Dummy realisieren kann,
eine Art Button, statt eines Dropdown-Feldes.

Ist es möglich mittels WebCmd das Dropdown durch einen "Button" (oder weiteren Dummy) zu ersetzen, sodass ich eine Art Checkbox simulieren kann?
Im Forum und auf anderen Seiten konnte ich leider nichts finden.

Also in etwa so:
attr du11 cmdIcon aktiv1.on:ios_on_fill aktiv1.off:ios_off_fill

Vielleicht könnt ihr mir helfen?!

Liebe Grüße

Mal als "Designstudie" meine Readingsgroup für die Bewässerung:
Die Anlagenphilosophie ist allerdings etwas anders. Gestartet wird (noch) nicht per Zeitsteuerung, sondern per Fernbedienung oder per Button im Rezept.
Dann laufen die Kreise mit den voreingestellten Zeiten durch. Hier der Code der RG:

Internals:
   DEF        <%sani_sprinkling>,<Pumpe>,<Kreis Hinten>,<Kreis Mitte>,<Kreis Vorn>,<Dosenring>,<Fehler- Verz.>,<Starte Rezept> Rez.:Pumpe,Hinten,Mitte,Vorn,Dosen,Fehler,Start
   FUUID      5cc16da9-f33f-fd76-20c7-d3970c5c7b0e4793
   NAME       Bewaesserung
   NR         2104
   NTFY_ORDER 50-Bewaesserung
   STATE      Initialized
   TYPE       readingsGroup
   changed    0
   mayBeVisible 1
   CONTENT:
     Rez1       1
     Rez2       1
     Rez3       1
     Rez4       1
     Rez5       1
     Rez6       1
   CONTENT2:
   DEVICES:
     ARRAY(0x407e990)
     ARRAY(0x3986480)
     ARRAY(0x4086d20)
     ARRAY(0x3d22cb8)
     ARRAY(0x4021840)
     ARRAY(0x3a45550)
     ARRAY(0x3afac40)
   fhem:
     lastDefChange 890
     last_update 1617779543.16239
   helper:
     DEF       
     commands   {Pumpe => "Pumpe:",Hinten => "Hinten:",Mitte => "Mitte:",Vorn => "Vorn:",Dosen => "Dosen:",Fehler => "Fehler:",'Start.1'  => 'setreading $DEVICE Start 0', 'Start.0'  => 'setreading $DEVICE Start 1'}
     nameStyle  style="color:yellow;;font-weight:bold"
     valueStyle style="text-align:center"
     positions:
       Rez1.Dosen 2:5
       Rez1.Fehler 2:6
       Rez1.Hinten 2:2
       Rez1.Mitte 2:3
       Rez1.Pumpe 2:1
       Rez1.Start 2:7
       Rez1.Vorn  2:4
       Rez2.Dosen 3:5
       Rez2.Fehler 3:6
       Rez2.Hinten 3:2
       Rez2.Mitte 3:3
       Rez2.Pumpe 3:1
       Rez2.Start 3:7
       Rez2.Vorn  3:4
       Rez3.Dosen 4:5
       Rez3.Fehler 4:6
       Rez3.Hinten 4:2
       Rez3.Mitte 4:3
       Rez3.Pumpe 4:1
       Rez3.Start 4:7
       Rez3.Vorn  4:4
       Rez4.Dosen 5:5
       Rez4.Fehler 5:6
       Rez4.Hinten 5:2
       Rez4.Mitte 5:3
       Rez4.Pumpe 5:1
       Rez4.Start 5:7
       Rez4.Vorn  5:4
       Rez5.Dosen 6:5
       Rez5.Fehler 6:6
       Rez5.Hinten 6:2
       Rez5.Mitte 6:3
       Rez5.Pumpe 6:1
       Rez5.Start 6:7
       Rez5.Vorn  6:4
       Rez6.Dosen 7:5
       Rez6.Fehler 7:6
       Rez6.Hinten 7:2
       Rez6.Mitte 7:3
       Rez6.Pumpe 7:1
       Rez6.Start 7:7
       Rez6.Vorn  7:4
     valueIcon:
       Start.0    sani_sprinkling.svg@wite
       Start.1    sani_sprinkling.svg@lime
       state      %devStateIcon
     values:
       formated:
         undef
         ARRAY(0x3ae6168)
         ARRAY(0x409ed60)
         ARRAY(0x3af7640)
         ARRAY(0x4033ec8)
         ARRAY(0x3702360)
         ARRAY(0x36fc138)
         ARRAY(0x3904588)
       orig:
         undef
         ARRAY(0x3a2d0b0)
         ARRAY(0x4f9bb0)
         ARRAY(0x38f14a0)
         ARRAY(0x26e77e8)
         ARRAY(0x36d9318)
         ARRAY(0x39b94b0)
         ARRAY(0x3a0fca8)
       prefixsuffix:
         undef
         ARRAY(0x40c7780)
         ARRAY(0x3a12eb8)
         ARRAY(0x39b47b8)
         ARRAY(0x36c6c98)
         ARRAY(0x37165c8)
         ARRAY(0x3a2d338)
         ARRAY(0x370a120)
Attributes:
   alias      Beregnungsanlage Rezeptparameter: Zeit in Minuten
   commands   {Pumpe => "Pumpe:",Hinten => "Hinten:",Mitte => "Mitte:",Vorn => "Vorn:",Dosen => "Dosen:",Fehler => "Fehler:",'Start.1'  => 'setreading $DEVICE Start 0', 'Start.0'  => 'setreading $DEVICE Start 1'}
   comment    https://forum.fhem.de/index.php?topic=54029.0
   group      Beregnung
   nameStyle  style="color:yellow;;font-weight:bold"
   nolinks    0
   nostate    0
   notime     0
   room       4_Garten
   valueIcon  { state => '%devStateIcon','Start.1'  => 'sani_sprinkling.svg@lime','Start.0' => 'sani_sprinkling.svg@wite',}
   valueStyle style="text-align:center"

Hallo fiedel,

dankeschön für den Anreiz.

Ich habe inzwischen auch einen recht guten Stand - ohne RG.
Ich werde mein Ergebnis dann auch hier posten.

Liebe Grüße

Mein Stand soweit.
Ohne Logik, Optik so gut wie fertig.


defmod dummy_BewaesserungAuto_VorneSeite dummy
attr dummy_BewaesserungAuto_VorneSeite alias vorne + Seite

defmod dummy_BewaesserungAuto_Hinten1 dummy
attr dummy_BewaesserungAuto_Hinten1 alias hinten1

defmod dummy_BewaesserungAuto_Hinten2 dummy
attr dummy_BewaesserungAuto_Hinten2 alias hinten2

defmod dummy_BewaesserungAuto_HeckeBeet dummy
attr dummy_BewaesserungAuto_HeckeBeet alias Hecke + Beet



attr dummy_BewaesserungAuto_.* setList \
state:on,off \
start:00:00,00:15,00:30,00:45,01:00,01:15,01:30,01:45,02:00,02:15,02:30,02:45,03:00,03:15,03:30,03:45,04:00,04:15,04:30,04:45,05:00,05:15,05:30,05:45,06:00,18:00,18:15,18:30,18:45,19:00,19:15,19:30,19:45,20:00,20:15,20:30,20:45,21:00,21:15,21:30,21:45,22:00,22:15,22:30,22:45,23:00,23:15,23:30,23:45,00:00 \
duration:15,30,45,60,90,120,180 mon:X,- tue:X,- wed:X,- thu:X,- fri:X,- sat:X,- sun:X,-

attr dummy_BewaesserungAuto_.* readingList \
state start duration mon tue wed thu fri sat sun



attr dummy_BewaesserungAuto_.* webCmd \
:start:duration:mon:tue:wed:thu:fri:sat:sun

attr dummy_BewaesserungAuto_.* webCmdLabel \
:Startzeit:Dauer:Mo:Di:Mi:Do:Fr:Sa:So

attr dummy_BewaesserungAuto_.* devStateIcon \
on:ios-on-green:off off:ios-off:on .*:ios-NACK:off


Hallo remo!

ich bin aktuell auch am Überlegen wie ich meine Bewässerungssteuerung relativ simple umsetze.
Die aktuelle Optik von dir, gefällt mir sehr gut! Ist im Endeffekt genau das was ich auch will.

Bist du mit der Logik schon vorangekommen?

Hallo vencam.

Sorry, dass ich so spät antworte!

Inzwischen hat sich viel getan.
Die Bewässerung läuft wie geplant.
Keine Aussetzer oder dergleichen.

Ich habe auch an der Optik gebastelt.
Die Möglichkeit mit den Tagen usw. hat sich (für mich) als unpraktisch erwiesen.

Ich habe es jetzt folgendermaßen gelöst (und bin sehr zufrieden) - Optik:


define dummy_Bewaesserung_aktiv dummy
attr dummy_Bewaesserung_aktiv alias aktiv

defmod dummy_BewaesserungAuto_VorneSeite dummy
attr dummy_BewaesserungAuto_VorneSeite alias vorne + Seite

defmod dummy_BewaesserungAuto_Hinten1 dummy
attr dummy_BewaesserungAuto_Hinten1 alias hinten1

defmod dummy_BewaesserungAuto_Hinten2 dummy
attr dummy_BewaesserungAuto_Hinten2 alias hinten2

defmod dummy_BewaesserungAuto_HeckeBeet dummy
attr dummy_BewaesserungAuto_HeckeBeet alias Hecke + Beet



attr dummy_Bewaesserung_aktiv readingList state start tage
attr dummy_Bewaesserung_aktiv setList state:on,off \
start:19:00,19:30,20:00,20:30,21:00,21:30,22:00,22:30,23:00,01:00,01:30,02:00,02:30,03:00,03:30,04:00,04:30,05:00 \
tage:1,2,3,4,5,6,7

attr dummy_Bewaesserung_aktiv webCmd :start:tage
attr dummy_Bewaesserung_aktiv webCmdLabel :Start:Tage
attr dummy_Bewaesserung_aktiv devStateIcon on:ios-on-green:off off:ios-off:on .*:ios-NACK:off

define notify_Bewaesserung_aktiv_EIN notify dummy_Bewaesserung_aktiv.on { fhem ("set at_BewaesserungAuto active") }
define notify_Bewaesserung_aktiv_AUS notify dummy_Bewaesserung_aktiv.off { fhem ("set at_BewaesserungAuto inactive") }
define notify_Bewaesserung_aktiv notify dummy_Bewaesserung_aktiv { \
fhem ("set at_BewaesserungAuto modifyTimeSpec {(ReadingsVal('dummy_Bewaesserung_aktiv','start',''))}") }



attr dummy_BewaesserungAuto_.* readingList state
attr dummy_BewaesserungAuto_.* setList state:15,30,45,60,90

attr dummy_BewaesserungAuto_.* webCmd state
attr dummy_BewaesserungAuto_.* webCmdLabel Dauer

attr dummy_Bewaesserung.* room BEWÄSSERUNG
attr dummy_Bewaesserung.* group 01_Zeitprogramme (autom. sprengen/wässern)



Auch die Logik möchte ich gerne teilen.


Logik:

define at_BewaesserungAuto at *{(ReadingsVal('dummy_Bewaesserung_aktiv','start','19:19'))} { \
my $tage = (ReadingsVal('dummy_Bewaesserung_aktiv','tage',''));; \
my $rest = ($yday % $tage);; \
my $dauer_VorneSeite = (ReadingsVal('dummy_BewaesserungAuto_VorneSeite','state','') * 60);; \
my $dauer_Hinten1 = (ReadingsVal('dummy_BewaesserungAuto_Hinten1','state','') * 60);; \
my $dauer_Hinten2 = (ReadingsVal('dummy_BewaesserungAuto_Hinten2','state','') * 60);; \
my $dauer_HeckeBeet = (ReadingsVal('dummy_BewaesserungAuto_HeckeBeet','state','') * 60);; \
my $dauer_total = ($dauer_VorneSeite + $dauer_Hinten1 + $dauer_Hinten2 + $dauer_HeckeBeet);; \
if ($rest == 0) \
{ fhem (" \
set schalter_Pumpe off;; \
set schalter_Ventil.* off;; \
set schalter_Pumpe on-for-timer $dauer_total;; \
set schalter_Ventil4 on-for-timer $dauer_Hinten2;; \
sleep $dauer_Hinten2;; \
set schalter_Ventil3 on-for-timer $dauer_Hinten1;; \
sleep $dauer_Hinten1;; \
set schalter_Ventil1 on-for-timer $dauer_VorneSeite;; \
sleep $dauer_VorneSeite;; \
set schalter_Ventil2 on-for-timer $dauer_HeckeBeet;; \
")};;}

attr at_BewaesserungAuto computeAfterInit 1



Wie gesagt, es funktioniert sehr gut.


Liebe Grüße


EDIT:
Ich probiere auch gerade etwas mit ESPEasy herum.
Der Regensensor läuft schon (für den Landroiden).
Bodenfeuchtesensoren kommen danach. Dann kann ich die Bewässerung noch weiter optimieren.

Vielleicht noch etwas für die Pros:

Ich stehe im Moment voll auf dem Schlauch. Logisches Denken ist gerade nicht so bei mir  :o

Mein Plan ist, mir irgendwie ausgeben zu lassen wann die nächste Sprengung erfolgt.
Also zB ,,heute" ,,morgen" ,,übermorgen" ,,Samstag" ,,Dienstag" usw.

Es muss doch irgendwie möglich sein zu ermitteln wenn zB:
Gestern gesprengt wurde und Tage auf 4 eingestellt ist, ich mir eine Ausgabe erzeugen kann die ,,Freitag" anzeigt. Bzw wenn ich ,,Tage" heute auf ,,2" ändere die Ausgabe live auf ,,morgen" springt wenn gestern gesprengt wurde.

Hab mit Addition/Subtraktionen von $yday und $wday experimentiert, aber ich habe gerade echt einen Knoten im Hirn!

Vielleicht hat jemand einen Anstoß für mich?!

Gruß

Hi,

es gab da mal einen sehr umfangreichen "Näherungsthread" mit vielleicht aus heutiger Sicht nicht sehr bezogenem Titel https://forum.fhem.de/index.php?topic=103238.0
Da ging es darum die Anzahl Tage zwischen einem Datum in der Zukunft und heute herauszufinden. Hat nur im umgekehrten Sinne etwas mit deiner Frage zu tun, erinnert mich aber daran :)

Abgeleitet aus dem Thread:
Tag ausgeben: {strftime('%A',localtime(time))}
Tag in 4 Tagen ausgeben {strftime('%A',localtime(time+3600*24*4))}
https://metacpan.org/pod/POSIX::strftime::GNU#FORMAT

So mache ich an andere Stelle aus 0 -> heute und 1 -> morgen - ansonsten die Zahl der Tage:
{ my $day = 4;; $day ? ($day>1 ? $day:"morgen"):"heute" }
Zusammen ergibt das:
{ my $day = 4;; $day ? ($day>1 ? strftime('%A',localtime(time+3600*24*$day)):"morgen"):"heute" }

Die Umstellung auf übermorgen überlasse ich Dir :)

Gruß Otto

Hi Otto,

Danke! Das hilft!

Ich brauche

den letzten Zeitpunkt des Sprengens + Anzahl der Tage = nächste Sprengung
nächste Sprenung - heute = (heute | morgen | übermorgen | <Mo-FR>)

Aber alles gut.
Dein Denkanstoß hat den Knoten gelöst ;)

Ich werde den fertigen Code dann posten.

Zitat von: remo am 13 Juli 2021, 20:58:11
Hallo vencam.

Sorry, dass ich so spät antworte!

Inzwischen hat sich viel getan.
Die Bewässerung läuft wie geplant.
Keine Aussetzer oder dergleichen.

Ich habe auch an der Optik gebastelt.
Die Möglichkeit mit den Tagen usw. hat sich (für mich) als unpraktisch erwiesen.

Ich habe es jetzt folgendermaßen gelöst (und bin sehr zufrieden) - Optik:

Code Auswählen Erweitern


define dummy_Bewaesserung_aktiv dummy
attr dummy_Bewaesserung_aktiv alias aktiv

defmod dummy_BewaesserungAuto_VorneSeite dummy
attr dummy_BewaesserungAuto_VorneSeite alias vorne + Seite

defmod dummy_BewaesserungAuto_Hinten1 dummy
attr dummy_BewaesserungAuto_Hinten1 alias hinten1

defmod dummy_BewaesserungAuto_Hinten2 dummy
attr dummy_BewaesserungAuto_Hinten2 alias hinten2

defmod dummy_BewaesserungAuto_HeckeBeet dummy
attr dummy_BewaesserungAuto_HeckeBeet alias Hecke + Beet



attr dummy_Bewaesserung_aktiv readingList state start tage
attr dummy_Bewaesserung_aktiv setList state:on,off \
start:19:00,19:30,20:00,20:30,21:00,21:30,22:00,22:30,23:00,01:00,01:30,02:00,02:30,03:00,03:30,04:00,04:30,05:00 \
tage:1,2,3,4,5,6,7

attr dummy_Bewaesserung_aktiv webCmd :start:tage
attr dummy_Bewaesserung_aktiv webCmdLabel :Start:Tage
attr dummy_Bewaesserung_aktiv devStateIcon on:ios-on-green:off off:ios-off:on .*:ios-NACK:off

define notify_Bewaesserung_aktiv_EIN notify dummy_Bewaesserung_aktiv.on { fhem ("set at_BewaesserungAuto active") }
define notify_Bewaesserung_aktiv_AUS notify dummy_Bewaesserung_aktiv.off { fhem ("set at_BewaesserungAuto inactive") }
define notify_Bewaesserung_aktiv notify dummy_Bewaesserung_aktiv { \
fhem ("set at_BewaesserungAuto modifyTimeSpec {(ReadingsVal('dummy_Bewaesserung_aktiv','start',''))}") }



attr dummy_BewaesserungAuto_.* readingList state
attr dummy_BewaesserungAuto_.* setList state:15,30,45,60,90

attr dummy_BewaesserungAuto_.* webCmd state
attr dummy_BewaesserungAuto_.* webCmdLabel Dauer

attr dummy_Bewaesserung.* room BEWÄSSERUNG
attr dummy_Bewaesserung.* group 01_Zeitprogramme (autom. sprengen/wässern)



Auch die Logik möchte ich gerne teilen.


Logik:

Code Auswählen Erweitern


define at_BewaesserungAuto at *{(ReadingsVal('dummy_Bewaesserung_aktiv','start','19:19'))} { \
my $tage = (ReadingsVal('dummy_Bewaesserung_aktiv','tage',''));; \
my $rest = ($yday % $tage);; \
my $dauer_VorneSeite = (ReadingsVal('dummy_BewaesserungAuto_VorneSeite','state','') * 60);; \
my $dauer_Hinten1 = (ReadingsVal('dummy_BewaesserungAuto_Hinten1','state','') * 60);; \
my $dauer_Hinten2 = (ReadingsVal('dummy_BewaesserungAuto_Hinten2','state','') * 60);; \
my $dauer_HeckeBeet = (ReadingsVal('dummy_BewaesserungAuto_HeckeBeet','state','') * 60);; \
my $dauer_total = ($dauer_VorneSeite + $dauer_Hinten1 + $dauer_Hinten2 + $dauer_HeckeBeet);; \
if ($rest == 0) \
{ fhem (" \
set schalter_Pumpe off;; \
set schalter_Ventil.* off;; \
set schalter_Pumpe on-for-timer $dauer_total;; \
set schalter_Ventil4 on-for-timer $dauer_Hinten2;; \
sleep $dauer_Hinten2;; \
set schalter_Ventil3 on-for-timer $dauer_Hinten1;; \
sleep $dauer_Hinten1;; \
set schalter_Ventil1 on-for-timer $dauer_VorneSeite;; \
sleep $dauer_VorneSeite;; \
set schalter_Ventil2 on-for-timer $dauer_HeckeBeet;; \
")};;}

attr at_BewaesserungAuto computeAfterInit 1



Wie gesagt, es funktioniert sehr gut.


Liebe Grüße


EDIT:
Ich probiere auch gerade etwas mit ESPEasy herum.
Der Regensensor läuft schon (für den Landroiden).
Bodenfeuchtesensoren kommen danach. Dann kann ich die Bewässerung noch weiter optimieren.

Servus remo,

kein Problem und danke, das du hier deine Logik mit uns teilst. Muss mir mal deinen Code in Ruhe anschauen.

Soweit funktioniert bei mir auch alles, Optik ist zufällig auch wie deine jetzige geworden :)
Habe allerdings mit einigen DOIFs gearbeitet, nicht ganz so übersichtlich aber für den Anfang reicht es erstmal.

Aktuell versuche ich für die Zisterne noch eine Logik zu programmieren, im Moment aber leider nicht viel Zeit.

Grüße

Ist ja witzig.
Ähnelt sich ja wirklich ziemlich  ;D

Für mein Konstrukt hat sich ergeben, dass wenn ich wässere, ich gleich alles ein mal hintereinander weg schalte. Heute Zone 1 und morgen Zone 2 macht bei mir keinen Sinn.

@Otto:
Erste Erfolge. Code kommt.

Musste heut morgen auch etwas schmunzeln, als ich deinen Screenshot gesehen habe :)

Da geb ich dir Recht! Im Endeffekt lässt mal 1x alles durchlaufen und gut.

Bodenfeuchte steht bei mir auch noch auf der Liste. Welchen Sensor möchtest du verwenden?

Auf einen Bodenfeuchtesensor hab ich mich noch nicht festgelegt.
Gibt ja einige. Hätte gerne einen, der auch etwas hält, zwecks Korrosion.

Ich werde wahrscheinlich diesen hier verwenden:

https://dvs-beregnung.de/kapazitiver-bodenfeuchte-sensor-inkl-temperaturmessung-truebner-smt50-arduino (https://dvs-beregnung.de/kapazitiver-bodenfeuchte-sensor-inkl-temperaturmessung-truebner-smt50-arduino)

Cool. Danke für den Tipp.

So. Fertig.



Nochmal zusammenfassend:

Mein Ziel war, mir anzeigen zu lassen, wann die nächste geplante Bewässerung in Abhängigkeit von Tage erfolgt.
Dabei sollte berücksichtigt werden wann die letzte geplante Bewässerung stattgefunden hat.
Die nächste geplante Bewässerung sollte dann komfortabel als heute / morgen / übermorgen / [Wochentag] angezeigt werden - relativ zu heute.

Dabei sollte sich die Anzeige / die Berechnung der nächsten geplanten Bewässerung dynamisch und in Echtzeit anpassen,
sobald der Wert Tage manuell geändert wird.



Mein Ansatz:

Es wird ein Hilfs-Dummy, welcher nach der geplanten Bewässerung, welche ja nach eingestelltem Zeitplan automatisch stattfindet, gesetzt.
Somit habe ich einen Zeitstempel des letzten Laufes.

define at_BewaesserungAuto at *{(ReadingsVal('dummy_Bewaesserung_aktiv','start','19:19'))} { \
my $tage = (ReadingsVal('dummy_Bewaesserung_aktiv','tage',''));; \
my $rest = ($yday % $tage);;

...

set dummy_Bewaess_lief on;; \
")};;}



Dann wird (nochmal Danke für den Ansatz, Otto) mittels regelmäßigem at (geht vielleicht auch schöner) etwas Zeit-Jongliererei betrieben:

define at_Bewaesserung_next at +*01:00 { \
my $active =  ReadingsVal('dummy_Bewaesserung_aktiv','state',''));; \
my $tage = (ReadingsVal('dummy_Bewaesserung_aktiv','tage',''));; \
my $then = (ReadingsTimestamp('dummy_Bewaess_lief', 'state', ''));; \
my $next1 = (time_str2num($then) + $tage * 60 * 60 * 24);; \
my $next2 = strftime("%Y-%m-%d",localtime($next1));; \
my $now = (strftime("%Y-%m-%d",localtime(time)));; \
my $diff1 = (((((time_str2num($next2)) - (time_str2num($now))) / 60) / 60) / 24);; \
my $nextDay = (strftime('%A',localtime(time+3600*24*$diff1)));; \
if ($active == on) { \
if ($diff1 == 0) {fhem("set dummy_Bewaesserung_next heute;;")};; \
if ($diff1 == 1) {fhem("set dummy_Bewaesserung_next morgen;;")};; \
if ($diff1 == 2) {fhem("set dummy_Bewaesserung_next übermorgen;;")};; \
if ($diff1 >= 3) {fhem("set dummy_Bewaesserung_next $nextDay;;")};; } \
else { {fhem("set dummy_Bewaesserung_next -;;")} };; }

Wobei der konkrete nächste "Termin" direkt in einen weiteren Dummy geschrieben wird.



Aktualisierung/Berechnung bei manueller Änderung von Tage:

define notify_Bewaesserung_aktiv notify dummy_Bewaesserung_aktiv { \
fhem ("set at_BewaesserungAuto modifyTimeSpec {(ReadingsVal('dummy_Bewaesserung_aktiv','start',''))};; set at_Bewaesserung_next execNow;;") }

set at_Bewaesserung_next execNow
ist ausschlaggebend.



Fertig.


Ich hoffe das ist nicht zu wirr und hilft dem einen oder anderen etwas.

Gerne kann ich auch mal meine gesamte Bewässerungsteuerung posten.

Gruß

Danke für deinen Code, mal schauen wie und ob ich das evtl. noch bei mir unterbringen kann.

Bin jetzt leider nicht "der" Programmierer aber wenn meins mal fertig ist, dann werde ich das hier auch veröffentlichen :)

Funktioniert echt gut.
Hätte man aber alles noch etwas eleganter machen können.
Aber mein FHEM ist sowieso eine Dauerbaustelle...

@EinenAdmin:

Ich hatte damals hier im Forum schon einen Account mit ,,remo".
Durch Inaktivität wurde der aber gelöscht.
Gibt es eine Möglichkeit, meinen alten Account mit meinem jetzigen zu verbinden, sodass meine Beiträge wieder einheitlich sind?

Gruß

Guten Abend.

Ich habe soeben einen Logikfehler in meinem at gefunden.

{$yday%$tage}

Ist falsch - in meinem Fall zumindest.
Der dummy ..._next zeigt nach dem ganzen Zeit-TamTam ,,heute" an, weil seit der letzten Wässerung 2 Tage vergangen sind, aber es schaltete heute nicht, weil $yday%$tage != 0 ist.

Werde das if rest==0 aus dem at durch ..._next eq ,,heute" ersetzen.
Somit würde tatsächlich alle x Tage seit der letzten Wässerung wieder gewässert werden und nicht in Abhängigkeit von $yday.

Wird getestet und dann gibt's ein sauberes Update.

Schönen Abend.

Alles aktualisiert und getestet.
Läuft.

Siehe meinen ersten Post auf Seite 1 - dort ist, falls Bedarf ist, meine komplette Bewässerung zu finden.


Schönen Sonntag.

@remo: Hab gesehen du arbeitest mit sleep Befehlen, bleibt da FHEM nicht komplett stehen?

Thema Pumpe:

Ich schalte meine Tauchpumpe (Zisterne), welche an einem Schütz hängt, mittels sonoff basic (tasmota).
Mit der Firmware hat man auch die Möglichkeit einen Timer zu setzen "pulsetime"  ...

Wird die Pumpe angeschalten, läuft der Timer und sie geht nach vorgegebener Zeit wieder aus.
Während der Bewässerung trigger ich die Pumpe alle paar Minuten, damit sie an bleibt. Also der Timer wird ständig neu gestartet.

Sollte FHEM aus welchem Grund auch immer, während der Bewässerung abstürzen, dann schaltet sich die Pumpe trotzdem selbständig ab.  :D

Zitat von: vencam am 18 Juli 2021, 12:05:26
@remo: Hab gesehen du arbeitest mit sleep Befehlen, bleibt da FHEM nicht komplett stehen?

er arbeitet mit fhem sleep Befehlen, die blockieren fhem nicht!

Zitat von: vencam am 18 Juli 2021, 12:05:26
@remo: Hab gesehen du arbeitest mit sleep Befehlen, bleibt da FHEM nicht komplett stehen?

Wenn danach ein fhem-Befehl folgt: nein
(so ich das schnell überflogen habe passt das hier wohl)

EDIT: war ja klar -> zu langsam ;)

Gruß, Joachim

@vencam:
Danke für den Hinweis.

@Otto:
Also doch ok?

Ein komplettes Schlafen kann ich wie genau testen?
Habe gerade während eines sleep mal einen anderen Aktor geschaltet und eine Berechnung durchführen lassen - hat funktioniert. FHEM hat sich wie erwartet verhalten. Hat also nicht den Eindruck eines Einfrierens gemacht.

Zitat von: remo am 18 Juli 2021, 13:37:53

@Otto:
Also doch ok?

Ein komplettes Schlafen kann ich wie genau testen?
Habe gerade während eines sleep mal einen anderen Aktor geschaltet und eine Berechnung durchführen lassen - hat funktioniert. FHEM hat sich wie erwartet verhalten. Hat also nicht den Eindruck eines Einfrierens gemacht.

Sebstverständlich ist das ok :)
vencam redet von/denkt an Perl sleep!
FHEM Sleep kann übrigens viel mehr als einfach nur ein Wartzeit:

Zitatsleep gefolgt von weiteren Befehlen ist vergleichbar mit einem namenlosen at oder notify Kommando, es führt die nachfolgenden Befehle aus, nachdem es die spezifizierte Zeitspanne gewartet hat bzw. ein Event welches dem <suchmuster> entspricht aufgetreten ist. Die verzögerung kann
in Sekunden (Millisekunden genau, da man Nachkommastellen spezifizieren kann)
als timespec (HH:MM or HH:MM:SS oder {perlfunc})
oder als suchmuster (Gerätename oder Gerätename:Event)
angegeben werden.

@Joachim Es freut mich immer, wenn wir zwei an verschiedenen Orten auf der Welt, die gleiche Frage lesen, fast die gleiche Antwort schreiben und nur mit Sekunden Unterschieden den Schreiben Knopf drücken. Ist doch völlig egal wer früher oder später ist :)

:)

Gut. Dankeschön  :)

Hallo zusammen,

so richtig rund läuft die Sache doch noch nicht.

Mein Dummy, der den Timestamp der letzten Bewässerung speichern soll, verliert den allerletzten Timestamp nach Neustart des physischen Servers.

Beispiel:

set dummy_Bewaess_lief on;; wird bei jeder Bewässerung ausgeführt.
ReadingsTimestamp('dummy_Bewaess_lief', 'state', '') ergibt dann danach z.B. 18:00:00

Dann passiert in  at_Bewaesserung_next etwas Zahlenspielerei, um den nächsten Zeitpunkt relativ zum letzten zu errechnen.

So weit, so gut. Läuft.

Findet jetzt die nächste Bewässerung statt, fängt der Spaß von vorne an und
ReadingsTimestamp('dummy_Bewaess_lief', 'state', '') ergibt dann z.B. 18:10:00

Nun startet der physische Server (Debian 10) neu und
ReadingsTimestamp('dummy_Bewaess_lief', 'state', '') ergibt dann wieder 18:00:00

Mittels geplantem save config habe ich versucht mir zu behelfen - aber das bringt leider nichts.
Mein Debian startet jeden Montagmorgen um 01:00 Uhr neu - seit gut vier Montagen bin ich nun ratlos.
FHEM scheint jedes Mal ds statefile vom letzten Speichern VOR dem Neustart auszulesen...

Hat vielleicht jemand eine Idee?

Schönen Wochenstart.

Hallo remo,

statefile wird beim ordentlichen Shutdown neu geschrieben. Da musst Du Dich nicht kümmern.
Entweder "ziehst Du den Stecker" oder mit der Zeit stimmt was nicht, oder "du selbst" manipulierst etwas ohne es zu wissen.
Einen statefile-1 gibt es mW nicht.

Was im statefile steht ist relativ leicht zu kontrollieren. Mach
systemctl stop fhem
Und dann
grep dummy_Bewaess_lief /opt/fhem/log/fhem.save

Wenn FHEM wieder läuft kannst Du auch reinschauen:
{qx(grep dummy_Bewaess_lief ./log/fhem.save)}

Gruß Otto

Hallo Otto.
Gut. Danke. Probiere ich aus. Vielleicht bringt mich das etwas näher an den Ursprung des Fehlers.
Aber sonderlich elegant ist mein Ansatz nicht, oder?
Eine dummy ,,on" schalten um mir dann später den Timestamp des ,,set xxx on" zu holen...?!
Wäre es vielleicht besser in den dummy dummy_Bewaesserung_aktiv ein Reading lief mit aufzunehmen welches dann im at den aktuellen Zeitstempel als Wert erhält?

EDIT:
,,Stecker ziehen" kommt dem schon recht nahe wenn ich FHEM den Server unterm hintern weg neustarte.
reboot  steht im Script.
systemctl reboot wäre doch dann abgebrach, oder?

Nach Eleganz hast Du aber nicht gefragt :)

reboot ist eigentlich ok, Du kannst Doch schauen ob fhem.save zu diesem Zeitpunkt geschrieben wurde.
reboot vom System sendet ein entsprechendes Signal an die Dienste, die werden ordentlich beendet, danach das System. Es sei denn, irgendwelche Wachhunde schlagen zu schnell zu, Timeouts werden überschritten o.ä.
on systemctl reboot was anderes ist als reboot weiß ich spontan nicht.

ZitatNach Eleganz hast Du aber nicht gefragt :)

Stimmt :D



grep dummy_Bewaess_lief /opt/fhem/log/fhem.save
--> setstate dummy_Bewaess_lief 2021-07-29 21:00:01 state on

{(ReadingsTimestamp('dummy_Bewaess_lief', 'state', ''))}
--> 2021-07-29 21:00:01 (Ok, beide identisch)

set dummy_Bewaess_lief on   // inzwischen wurde bewässert
grep dummy_Bewaess_lief /opt/fhem/log/fhem.save
--> setstate dummy_Bewaess_lief 2021-07-29 21:00:01 state on (falsch)
{(ReadingsTimestamp('dummy_Bewaess_lief', 'state', ''))}
--> 2021-08-02 20:15:12 (richtig)



systemctl stop fhem
systemctl start fhem



grep dummy_Bewaess_lief /opt/fhem/log/fhem.save
--> setstate dummy_Bewaess_lief 2021-07-29 21:00:01 state on (falsch, alter Wert)

{(ReadingsTimestamp('dummy_Bewaess_lief', 'state', ''))}
--> 2021-07-29 21:00:01 (falsch, alter Wert)

Wurde fhem.save denn zum reboot Zeitpunkt geschrieben?
{qx(ls -lha ./log/fhem.save)}
Was steht in global?
list global statefile

ZitatWurde fhem.save denn zum reboot Zeitpunkt geschrieben?

Nein.

Reboot: 2021-08-02 20:30:00


{qx(ls -lha ./log/fhem.save)}
--> -rwxrwxrwx 1 fhem dialout 103K Aug  2 15:16 ./log/fhem.save





date unter Debian
--> Mo 2. Aug 20:31:50 CEST 2021 (passt)

list global statefile
--> global                   ./log/fhem.save

Das ist unschön, da hast Du mal über überbügelt

Zitat-rwxrwxrwx

x - ist sinnlos
w -schreiben muss nur fhem können

Aber das ist nicht der Fehler. Ich habe keine Ahnung wer verhindert, dass Dein statefile beim reboot geschrieben wird.
Mach mal einen normalen shutdown reboot in FHEM und kontrolliere danach.

ZitatDas ist unschön, da hast Du mal über überbügelt

Ist ein Relikt aus einem alten Tutorial von vor x Jahren.

ZitatMach mal einen normalen shutdown reboot in FHEM und kontrolliere danach.

{qx(ls -lha ./log/fhem.save)}
--> -rwxrwxrwx 1 fhem dialout 104K Aug  2 20:42 ./log/fhem.save (ok)

save config
bewirkt übrigens dasselbe. Zeit auch ok.

save config
rufe ich ja auch während der Bewässerung auf

direkt nach
set dummy_Bewaess_lief on

define at_BewaesserungAuto at *{(ReadingsVal('dummy_Bewaesserung_aktiv','start','19:19'))} { \
my $next = (ReadingsVal('dummy_Bewaesserung_next','state',''));; \
my $dauer_VorneSeite = (ReadingsVal('dummy_BewaesserungAuto_VorneSeite','state','') * 60);; \
my $dauer_Hinten1 = (ReadingsVal('dummy_BewaesserungAuto_Hinten1','state','') * 60);; \
my $dauer_Hinten2 = (ReadingsVal('dummy_BewaesserungAuto_Hinten2','state','') * 60);; \
my $dauer_HeckeBeet = (ReadingsVal('dummy_BewaesserungAuto_HeckeBeet','state','') * 60);; \
my $dauer_total = ($dauer_VorneSeite + $dauer_Hinten1 + $dauer_Hinten2 + $dauer_HeckeBeet);; \
if ($next eq 'heute') \
{ fhem (" \
set schalter_Pumpe off;; \
set schalter_Ventil.* off;; \
set dummy_Bewaess_lief on;; \
save config;;
set at_Bewaesserung_next execNow;; \
set schalter_Pumpe on-for-timer $dauer_total;; \
set schalter_Ventil4 on-for-timer $dauer_Hinten2;; \
sleep $dauer_Hinten2;; \
set schalter_Ventil3 on-for-timer $dauer_Hinten1;; \
sleep $dauer_Hinten1;; \
set schalter_Ventil1 on-for-timer $dauer_VorneSeite;; \
sleep $dauer_VorneSeite;; \
set schalter_Ventil2 on-for-timer $dauer_HeckeBeet;; \
")};;}

--> Das war ja mein Versuch aus Verzweiflung.
Das funktioniert auch Tag für Tag tadellos (auch wenn nicht ganz so elegant gelöst), aber wehe der Server macht seinen reboot am Montagmorgen um 01:00 Uhr, dann ist auf einmal das "alte" statefile wieder da....

Was gibt das zurück?list global autosave
Du sagst ja indirekt er ändert beim reboot die Datei?
Also mach mal alle Schritte zur Kontrolle das save config funktioniert und dann ein reboot und danach wieder Kontrolle?
Irgendwie klingt es mystisch ...

list global autosave
--> global                   0

ZitatDu sagst ja indirekt er ändert beim reboot die Datei?

So stellt sich das zumindest dar.

ZitatAlso mach mal alle Schritte zur Kontrolle das save config funktioniert und dann ein reboot und danach wieder Kontrolle?

Das war letzten Montag der Fall - dadurch bin ich dann bei save config gelandet.
Das statefile hat anfangs den manuellen reboot überlebt.
Daher war ich glücklich save config "entdeckt" zu haben.

Bis heute morgen.
Das manuelle sudo reboot lässt das statefile in Ruhe - nach wie vor und gerade getestet
(grep dummy_Bewaess_lief /opt/fhem/log/fhem.save)

Das geplante sudo reboot lädt anscheinend eine "alte Version" des statefile.

Verwirrend. Ich weiß  :-[


EDIT:
Jetzt mal ne ganz blöde Frage und nicht hauen:
Benötigt das statefile die Log-Datei aus dem selben Verzeichnis?
Also: /opt/fhem/log/fhem-YYYY-MM.log
oder die aus /var/log/ ?

Zitat von: remo am 02 August 2021, 21:31:33
Daher war ich glücklich save config "entdeckt" zu haben.

Ich denke ja diese Entdeckung ist völlig unnütz. Die Verwendung in Scripten wird eigentlich nicht empfohlen.

Zitatautosave
Der Standardwert 1 aktiviert einige Module nach einer Konfigurationsänderung automatisch zu speichern z.B. wenn ein neues Gerät erstellt wurde. Treten beim FHEM Start Konfigurationsfehler auf wird diese Funktion automatisch deaktiviert (0).

Bei der Einstellung autosave 0 wird ein save config im Code / Script nicht funktionieren.

Das statefile ist eine Textdatei die geschrieben wird, die "braucht" keine andere Datei. ::)

Du verschweigst etwas?

attr global autosave 0
So steht's in meiner FHEM.cfg

ZitatBei der Einstellung autosave 0 wird ein save config im Code / Script nicht funktionieren.

Gut zu wissen. Also keine Entdeckung :D

ZitatDu verschweigst etwas?

In meinem wöchentlichen reboot-Skript lasse ich Log-Dateien löschen, auch die von FHEM.

Dann sage ich mal: überprüfe dieses Script! Du sagst ja schlussendlich selbst, das macht was mit dem fhem.save File.

Ich habe keine Vorstellung was. ;)

Zum Nachweis würde ich als erstes nur ein geplantes reboot ohne alles weitere testen :)

So weit war ich schon.
Das einzige was dort drin steht und Einfluss auf FHEM haben könnte ist das Löschen der Logs.
Der Rest bezieht sich auf andere Dinge.

Führe ich das Skript manuell aus funktioniert alles seit der save config-Entdeckung.
Läuft das Skript geplant (cronjob) tritt dieses Verhalten auf.
Per cronjob läuft aber auch nichts weiter vor, zu oder nach diesem Zeitpunkt.
Der cronjob läuft schon seitdem ich FHEM verwende.

Ich hatte bisher keine Probleme mit dem statefile oder ,,eigenartigem" Verhalten.
Zumindest fällt mir das erst jetzt mit meinem dummy auf.


Was aus FHEM heraus noch NACH dem cronjob (01:00) läuft, fällt mir gerade ein, ist um 03:15:
{ fhem ("save config;; sleep 5;; update all;; sleep 300;; shutdown restart;;");; }

Das statefile hat aber nie den Stempel 03:15 - habe ich jedenfalls noch nicht beobachtet.

UND:
Otto, vielen Dank bisher für deine Unterstützung!!!
Ich weiß deine Geduld und Mühe sehr zu schätzen!!!

naja save config ist ohne Wirkung, weil autosave auf 0 steht. save config ist aber auch nicht nur save fhem.save

Kannst Du Das Log von FHEM kontrollieren, ob es bei deinem cronjob ordentlich beendet wird? Also die gleiche Sequenz als wenn Du den reboot interactiv machst.

Ich denke ja nach wie vor: Du machst irgendwas "böses" in deinem Script, FHEM wird nicht ordentlich beendet, ein watchdog schlägt zu und killt den Prozess.

Aber wenn ich richtig liege, hast Du noch was anderes behauptet? Nachdem die fhem.save Datei schon richtig war, holt Dein cronjob ein altes File hervor!? Wenn das wirklich so ist, hast Du entweder einen Kobold im System oder Du kennst Dein Script nicht komplett. :)

Gut. Reicht für heute  ;)
Danke für deine Zeit.
Ich melde mich..

Geheimnis gelüftet.
Kein Kobold. Und mein Skript kenne ich auch, weil selbst geschrieben  ;)

Dass das statefile beim manuellen reboot mal intakt blieb und mal nicht ließ sich nicht zuverlässig reproduzieren.
Ich vermute eine ungünstige Konstellation/Abfolge von set dummy_Bewaess_lief on automatischer statefile-Speicherung durch FHEM und reboot .

Der geplante reboot hingegen, also der Aufruf des Skriptes (auch über cron), holte ja jedesmal ein "altes" statfile wieder hervor.

Beim manuellen Ausführen von systemctl stop fhem dauerte es einen Moment (ca. 5 Sekunden) bis der Befehl durch war.
Das ließ mich nachdenken.



grep shutdown /opt/fhem/log/fhem-2021-08.log
zeigte mir, dass der Shutdown in ca. 10 Sekunden stattfinden wird.

Da ein reboot, ob automatisch oder manuell, das System umgehend und ohne Verzögerung neustartet,
scheint systemctl stop fhem nicht stattzufinden.

Heißt: systemctl stop fhem + reboot = statefile ok

Ich habe systemctl stop fhem in mein Skript, vor reboot, mit aufgenommen.
Mehr nicht --> alles gut.



Otto, danke für das Weisen in die richtige Richtung.