NEWS
[Vorlage] Gartenbewässerung mit 6 Ventilen
-
@stratos-gkrekidis ah Denkfehler auf meiner Seite.
Du nutzt Power 7 und 8 für die Pumpe etc.
Den Anwendugsfall habe ich nicht bedacht.
Das kann ich aber einigermaßen schnell einbauen
@kuddel said in [Vorlage] Gartenbewässerung mit 6 Ventilen:
@stratos-gkrekidis ah Denkfehler auf meiner Seite.
Du nutzt Power 7 und 8 für die Pumpe etc.
Den Anwendugsfall habe ich nicht bedacht.
Das kann ich aber einigermaßen schnell einbauen
Beim tasmota passwortgeschützte weboberfläche funktioniert deine commands nicht
bild 2 mein vorschlag.
-
@kuddel said in [Vorlage] Gartenbewässerung mit 6 Ventilen:
@stratos-gkrekidis ah Denkfehler auf meiner Seite.
Du nutzt Power 7 und 8 für die Pumpe etc.
Den Anwendugsfall habe ich nicht bedacht.
Das kann ich aber einigermaßen schnell einbauen
Beim tasmota passwortgeschützte weboberfläche funktioniert deine commands nicht
bild 2 mein vorschlag.@stratos-gkrekidis achja die PW Problematik.
Sorry habe ich ganz vergessen.
Baue ich dann direkt in v3.1.0 mit ein.
Wie besprochen, pro Tasmota Aktor einen User und ein PW.
Die neuen DP-Namen ab Tasmota 9.4.0 habe ich heute in Version 3.0.0 eingebaut
-
@qlink aktuell fehler mit der Ansatz, wie ich per Blockly prüfen kann, ob die ON_TIME DPs vorhanden sind.
Man könnte es natürlich am Anfang mit angeben.
HM-Tp = Wired
Aber eine automatische Erkennung wäre natürlich schöner. Ich muss da nochmal bisschen testen
@kuddel said in [Vorlage] Gartenbewässerung mit 6 Ventilen:
@qlink aktuell fehler mit der Ansatz, wie ich per Blockly prüfen kann, ob die ON_TIME DPs vorhanden sind.
Man könnte es natürlich am Anfang mit angeben.
HM-Tp = Wired
Aber eine automatische Erkennung wäre natürlich schöner. Ich muss da nochmal bisschen testen
Hi Kuddel, wegen dem Thema Homematic Wired und keine ON_TIME DPs hätte ich folgenden Beitrag gefunden:
https://forum.iobroker.net/topic/27985/prüfen-ob-datenpunkt-existiert/13
Mit existState kann man anscheinend prüfen, ob ein Datenpunkt vorhanden ist oder nicht und dann entsprechend weitere Schritte setzen...
Wäre das nicht ein Ansatz, wie man automatisch in deinem Script checken kann ob Homematic Funk oder Homematic Wired im Einsatz ist ?
Also, falls ON_TIME DP nicht existiert, dann ...
Bete Grüße
-
@kuddel said in [Vorlage] Gartenbewässerung mit 6 Ventilen:
@qlink aktuell fehler mit der Ansatz, wie ich per Blockly prüfen kann, ob die ON_TIME DPs vorhanden sind.
Man könnte es natürlich am Anfang mit angeben.
HM-Tp = Wired
Aber eine automatische Erkennung wäre natürlich schöner. Ich muss da nochmal bisschen testen
Hi Kuddel, wegen dem Thema Homematic Wired und keine ON_TIME DPs hätte ich folgenden Beitrag gefunden:
https://forum.iobroker.net/topic/27985/prüfen-ob-datenpunkt-existiert/13
Mit existState kann man anscheinend prüfen, ob ein Datenpunkt vorhanden ist oder nicht und dann entsprechend weitere Schritte setzen...
Wäre das nicht ein Ansatz, wie man automatisch in deinem Script checken kann ob Homematic Funk oder Homematic Wired im Einsatz ist ?
Also, falls ON_TIME DP nicht existiert, dann ...
Bete Grüße
-
@kuddel said in [Vorlage] Gartenbewässerung mit 6 Ventilen:
@stratos-gkrekidis ah Denkfehler auf meiner Seite.
Du nutzt Power 7 und 8 für die Pumpe etc.
Den Anwendugsfall habe ich nicht bedacht.
Das kann ich aber einigermaßen schnell einbauen
Beim tasmota passwortgeschützte weboberfläche funktioniert deine commands nicht
bild 2 mein vorschlag.@stratos-gkrekidis ich habe jetzt PulseTime für Tasmota bis PulseTime8 berücksichtig für alle Ventil-Aktoren sowie Pumpen-Aktor und Netzteil-Aktor.
Des Weiteren habe ich jetzt die Credentials für Tasmota berücksichtigt
Da ich weder einen Tasmota Aktor mit 8 Kanälen haben, noch eine Anmeldung an meinen Tasmota-Aktoren, wäre es klassen, wenn du die neue Version 3.1.0 einmal testen könntest:
-
@kuddel said in [Vorlage] Gartenbewässerung mit 6 Ventilen:
@qlink aktuell fehler mit der Ansatz, wie ich per Blockly prüfen kann, ob die ON_TIME DPs vorhanden sind.
Man könnte es natürlich am Anfang mit angeben.
HM-Tp = Wired
Aber eine automatische Erkennung wäre natürlich schöner. Ich muss da nochmal bisschen testen
Hi Kuddel, wegen dem Thema Homematic Wired und keine ON_TIME DPs hätte ich folgenden Beitrag gefunden:
https://forum.iobroker.net/topic/27985/prüfen-ob-datenpunkt-existiert/13
Mit existState kann man anscheinend prüfen, ob ein Datenpunkt vorhanden ist oder nicht und dann entsprechend weitere Schritte setzen...
Wäre das nicht ein Ansatz, wie man automatisch in deinem Script checken kann ob Homematic Funk oder Homematic Wired im Einsatz ist ?
Also, falls ON_TIME DP nicht existiert, dann ...
Bete Grüße
@qlink habe mal eben kurz mit einem HomeMatic Heizkörper Aktor geprüft.
Ergenis: "DP nicht vorhanden"
Funzt also.
D.h. ich würde jetzt für jeden Ventil-Aktor prüfen, ob der DP vorhanden ist.
Falls nicht, wird der Typ von "HM" auf "HM-Wired" geändert.Somit wird der Aktor aktiviert und bekommt keine OnTime.
Somit müssten die Fehlermeldungen im Log verschwinden.
Wäre das dann eine Lösung für dein Problem ?
-
@qlink habe mal eben kurz mit einem HomeMatic Heizkörper Aktor geprüft.
Ergenis: "DP nicht vorhanden"
Funzt also.
D.h. ich würde jetzt für jeden Ventil-Aktor prüfen, ob der DP vorhanden ist.
Falls nicht, wird der Typ von "HM" auf "HM-Wired" geändert.Somit wird der Aktor aktiviert und bekommt keine OnTime.
Somit müssten die Fehlermeldungen im Log verschwinden.
Wäre das dann eine Lösung für dein Problem ?
Das wäre super und würde mir schonmal gut helfen :)
Das Thema mit der fehlenden Sicherheitsschicht ohne OnTime beschäftigt mich allerdings noch ...
Die einzige Möglichkeit bei den 12/7er HM Wired Modulen eine ähnliche Sicherheit wie deine OnTime Variante bei der Funk-Version einzubauen wäre die Nutzung von Direktverknüpfungen mit einer fix eingestellten Ausschaltverzögerung.
Dazu könnte ich auf der CCU eine Direktverknüpfung zwischen einem virtuellen Taster (z.B. mit dem Namen "Ventil1_10min") und dem Ausgang an dem das Ventil angeschlossen ist erstellen. Bei dieser DV stelle ich in der CCU eine fixe Ausschaltverzögerung von 10min ein.
Wäre es möglich dein Skript so zu erweitern, dass man, falls die Prüfung HM-Wired ergibt, die Möglichkeit hat, alternativ zu den normalen Ventil Aktoren States, die States dieser virtuellen Taster angibt ?
In der VIS müsste man natürlich die gleichwertige Dauer der Bewässerung trotzdem angeben, damit die % Anzeigen, die Bewässerungsmengen etc. stimmen ...
Damit wäre dein Script bei HM-Wired zwar nicht mehr ganz so komfortabel, aber zumindest genauso sicher wie bei Einsatz von HM-Funk... sprich die Ventile würde fix nach 10min schließen, auch wenn in der Zwischenzeit iobroker aus irgendeinem Grund nicht mehr erreichbar wäre.
Beste Grüße
-
Das wäre super und würde mir schonmal gut helfen :)
Das Thema mit der fehlenden Sicherheitsschicht ohne OnTime beschäftigt mich allerdings noch ...
Die einzige Möglichkeit bei den 12/7er HM Wired Modulen eine ähnliche Sicherheit wie deine OnTime Variante bei der Funk-Version einzubauen wäre die Nutzung von Direktverknüpfungen mit einer fix eingestellten Ausschaltverzögerung.
Dazu könnte ich auf der CCU eine Direktverknüpfung zwischen einem virtuellen Taster (z.B. mit dem Namen "Ventil1_10min") und dem Ausgang an dem das Ventil angeschlossen ist erstellen. Bei dieser DV stelle ich in der CCU eine fixe Ausschaltverzögerung von 10min ein.
Wäre es möglich dein Skript so zu erweitern, dass man, falls die Prüfung HM-Wired ergibt, die Möglichkeit hat, alternativ zu den normalen Ventil Aktoren States, die States dieser virtuellen Taster angibt ?
In der VIS müsste man natürlich die gleichwertige Dauer der Bewässerung trotzdem angeben, damit die % Anzeigen, die Bewässerungsmengen etc. stimmen ...
Damit wäre dein Script bei HM-Wired zwar nicht mehr ganz so komfortabel, aber zumindest genauso sicher wie bei Einsatz von HM-Funk... sprich die Ventile würde fix nach 10min schließen, auch wenn in der Zwischenzeit iobroker aus irgendeinem Grund nicht mehr erreichbar wäre.
Beste Grüße
-
@qlink sollte es nicht funktionieren, wenn du als Aktor nich den HM-Wired Aktor, sondern direkt den virtuellen Taster hinterlegst ?
Dann schaltet das Skript den virtuellen Taster ein, und der Taster über die CCU den Aktor
-
Würde das Skript nicht nach Ablauf der 10min wieder eine Aktion bei dem Taster setzen ?
Beispiel Laufzeit Ventil 1 = 10 Min
HM-Wired:
Start Bewässerung: Ventil 1 anschalten -> set Aktor true
Ende Laufzeit Ventil 1: Ventil 1 ausschalten -> set Aktor falseWas für ein Typ ist der virtuelle Taster ?
Hat der true / false oder steht der immer auf false und ist nur beim Betätigten true ?Ich bräuchte mal einen Screenshot vom virtuellen Taster
-
Beispiel Laufzeit Ventil 1 = 10 Min
HM-Wired:
Start Bewässerung: Ventil 1 anschalten -> set Aktor true
Ende Laufzeit Ventil 1: Ventil 1 ausschalten -> set Aktor falseWas für ein Typ ist der virtuelle Taster ?
Hat der true / false oder steht der immer auf false und ist nur beim Betätigten true ?Ich bräuchte mal einen Screenshot vom virtuellen Taster
-
@qlink das habe ich befürchtet.
Mein Skript würde aktuell den Aktor starten und beim stoppen den virtuellen Taster noch einmal auslösen.
Ich könnte jetzt natürlich noch eine Falls-Abfrage beim Ausschalten einbauen, dass das Ausschalten nur bei Aktoren ausgeführt wird, die ungleich HM-Wired sind, aber das wäre dann eine absolute Sonderlocke.
Für jeden weiteren User, der HM-Wired Aktoren verwenden will, würde das Skript dann die Aktore nicht mehr abschalten.
Das mit den Virtuellen Tastern funzt also nicht sauber.
-
@stratos-gkrekidis ich habe jetzt PulseTime für Tasmota bis PulseTime8 berücksichtig für alle Ventil-Aktoren sowie Pumpen-Aktor und Netzteil-Aktor.
Des Weiteren habe ich jetzt die Credentials für Tasmota berücksichtigt
Da ich weder einen Tasmota Aktor mit 8 Kanälen haben, noch eine Anmeldung an meinen Tasmota-Aktoren, wäre es klassen, wenn du die neue Version 3.1.0 einmal testen könntest:
@kuddel said in [Vorlage] Gartenbewässerung mit 6 Ventilen:
@stratos-gkrekidis ich habe jetzt PulseTime für Tasmota bis PulseTime8 berücksichtig für alle Ventil-Aktoren sowie Pumpen-Aktor und Netzteil-Aktor.
Des Weiteren habe ich jetzt die Credentials für Tasmota berücksichtigt
Da ich weder einen Tasmota Aktor mit 8 Kanälen haben, noch eine Anmeldung an meinen Tasmota-Aktoren, wäre es klassen, wenn du die neue Version 3.1.0 einmal testen könntest:
Hallo @kuddel dein letztes update funktioniert prima.Vielen Dank
-
@estegemann wenn du ohne eine VIS arbeitest, dann ist ein wenig Aufwand.
Um die Automatik zu aktivieren, muss folgender DP auf true:
javascript.0.bewaesserung.bewaesserung_automatikDamit die Bewässerung zu einer festen Zeit startet, muss dieser DP aktiviert werden:
javascript.0.bewaesserung.zeitplan.feste_startzeit_1.feste_startzeit_1_aktivDort dann die gewünschte Startzeit eintragen:
javascript.0.bewaesserung.zeitplan.feste_startzeit_1.feste_startzeit_1_uhrzeit_startUnd dann musst du noch die Laugzeoit pro Ventil in Minuten einstellen:
javascript.0.bewaesserung.ventile.ventil_1.ventil_1_dauer_in_minMit einer VIS ist das natürlich alles einfacher. Den Export von meinen VIS-Seiten zur Bewässerung gibt es hier.
-
@kuddel
Hey Kuddel, gibt es auch die Möglichkeit alle 2 oder 3 Tagen automatisch die Bewässerung zu starten?Gruß SiKo
-
@kuddel
Ja genau. Wenn man feste Tage wählt, egal ob alle 2 oder 3, geht es ja nie auf. Aktuell bewässere ich alle 3 Tage. Ich möchte noch einen Regensensor involvieren. Dann soll z.B. wenn dieser auslöst erst wieder 3 Tage danach bewässert werden. Bin selbst noch am testen, da mein CRON nicht zuverlässig läuft. -
@kuddel
Ja genau. Wenn man feste Tage wählt, egal ob alle 2 oder 3, geht es ja nie auf. Aktuell bewässere ich alle 3 Tage. Ich möchte noch einen Regensensor involvieren. Dann soll z.B. wenn dieser auslöst erst wieder 3 Tage danach bewässert werden. Bin selbst noch am testen, da mein CRON nicht zuverlässig läuft. -
@siko die Tage könnte man in einem DP eintragen und daraus den CRON Job bauen.
Beispiel: alle 3 Tage -> Tage = 3
Der Cron sieht dann so aus:
Er ist dann abhängig vom Kalendertag.
-
@estegemann wenn du Jarvis nutzt, musst du natürlich nur die DPs bei dir einbauen.
Wenn du Fragen hast, kannst du natürlich gern auf mich zu kommen
@kuddel Irgendwie habe ich Probleme beim Script import.
Ist es normal, dass alle Blöcke überlagert sind und ich jetzt versuchen muss diese wieder auseinander zu pflücken? Hast du eine Idee warum die Darstellung ist wie auf dem untenstehenden Bild. Das macht es ungemein schwierig, das Skript auf meine Situation anzupassen.
Vielen Dank und besten Gruß,
Eric -
@kuddel Irgendwie habe ich Probleme beim Script import.
Ist es normal, dass alle Blöcke überlagert sind und ich jetzt versuchen muss diese wieder auseinander zu pflücken? Hast du eine Idee warum die Darstellung ist wie auf dem untenstehenden Bild. Das macht es ungemein schwierig, das Skript auf meine Situation anzupassen.
Vielen Dank und besten Gruß,
Eric
Support us
755
Online32.5k
Benutzer81.7k
Themen1.3m
Beiträge