Z-Wave -Story und Meine Entscheidung für's HCL

@TE999:

 da die Kommunikation über Http Protokolle laufen ist das ganze etwas träge. 

Hast Du dir meinen Post https://www.symcon.de/forum/threads/42985-Z-Wave-Story-und-Meine-Entscheidung-f%C3%BCr-s-HCL?p=421833#post421833 durchgelesen ?

Das Problem mit der gefühlt sehr langsamen Ausführung liegt z.Zt. an dem Zusammenspiel PHP und CURL. Es hat hier erstmal nix mit HTTP zu tun ! Ich habe deine Kommandos von ANfng an auf reine HTTP Requests umgestellt. Es liegen alle meine Schaltbefehle im bereich von gefühlt 0,1-0,3 Sec. Bereich. Von vorher bis zu 2-3 Sec. :eek:

lueralba

Hallo lueralba,
hallo Thomas,
hallo Markus,

ich hab es geschafft: Ich habe eine HCL-Szene angelegt, die bei Status-Änderungen am Plug ein virtuelles Modul aufruft.

Im virtuellen Modul steht diese Zeile:

PUT /hook/hcl.php?runScriptID=12345 HTTP/1.10x0D0x0A0x0D0x0A

Das WebHook-Script wird über :3777/hook/hcl.php?runScriptID=12345 (klappt auch direkt im Browser) aufgerufen und hat diesen Inhalt:

if (isset($_GET["runScriptID"])) {
    $ScriptID = (int)$_GET["runScriptID"];
    IPS_RunScript($ScriptID);
    IPS_LogMessage($_IPS['SELF'], "Skript mit der ID ".$ScriptID." wurde aufgerufen! - Skript #".$_IPS['SELF']);
}

Das Skript mit der ID 12345 liest dann die Geräte und deren Parameter über folgenden HTTP-Befehl aus:

http://<user>:<password>@<ip-adress>/api/devices

Danke für Eure Hilfe und die Denkanstösse.

Viele Grüße aus dem Unterallgäu
Harry

Hallo Harry,

schön zu hören :slight_smile:

ich habe inzwischen zwei FGS223, einen FGD212, ein FGMS-001 5g 4-in-1 Multisensor sowie einen alten Düwi Wandsender von 2012 (Assoziation mit dem Dimmer über HCL) umgelernt.
Und es läuft einwandfrei zwischen HCL und IPS :smiley:

Gerade die (beiden) Verbrauchs-Messwerte der Doppelschalter kommen einwandfrei rüber.

Gruß
lueralba

Die Hoffnung habe ich auch.

Ich werde meine Skripte ausbauen und optimieren. Dann werde ich ausgiebig testen und danach alle 64 Plugs umziehen.

Ich bin mit der RaZberry2-IPS-Lösung nie richtig glücklich gewesen, es hat nicht zuverlässig funktioniert. Wenn alles umgestellt ist, dann fliegt das RaZberry2-Modul aus der SymBox raus.

Viele Grüße aus dem Unterallgäu
Harry

@lueralba
@harry28

Danke für Eure Hinweise. Gemeinsam kommt man viel schneller voran. Wenn ich mal wieder etwas Zeit finde werde ich meine Scripte noch einmal überarbeiten. Das wichtigste ist es gibt endlich eine Lösung wie man alle Werte von den Geräten sauber lesen und verarbeiten kann.

@harry28
Mit Hilfe Deiner Webseite habe ich vor 4 Jahren mein ersten Razberry in Symcon eingebunden.

Gruß Thomas

Dann kennen wir uns ja schon ewig. [emoji3][emoji106]

Es freut mich, wenn meine Seiten ein klein wenig weiterhelfen, ich investiere doch einiges an Zeit dafür.

Genauso freue ich mich über die Hilfe in diesem Forum und die interessanten Lösungen. Hier habe ich bisher immer etwas gefunden!

Oft brauche ich auch nur eine kleine „Anschubfinanzierung“ um eine Lösung für mein SmartHome zu finden. Ich habe leider kaum jemand zum Fachsimpeln oder Ideen diskutieren. Danke an Euch.

Viele Grüße aus dem Unterallgäu
Harry

So, nun sind alle 64 Steckdosen am HCL angelernt und alle Skripte umgestellt.

Sie laufen prima und alle ZWave-Komponenten sind in IPS entfernt. Es gibt keine Zombie-Variablen mehr und keine „Geisterhaus“-Schaltvorgänge. Mein IP-Symcon ist nun ZWave-frei.

Die Steckdosen lassen sich über die HCL-Oberfläche prima verwalten, inklusive Firmwareaktualisierung und ZWave-Backup.

Das Exkludieren in IPS hat wieder nicht funktioniert, so dass ich alle Steckdosen auf Werkseinstellungen zurückgesetzt habe, bevor ich sie am HCL inkludiert habe. Es war natürlich eine große Rennerei durch das ganze Haus …

Aber es war eine sehr gute Entscheidung aufs HCL umzusteigen. Das RaZberry2-Modul wird jetzt aus der SymBox ausgebaut und in den Vorruhestand geschickt.

Viele Grüße aus dem Unterallgäu
Harry

Moin… ich habe jetzt auch mal ein HCL für die Installation bei Schwiegereltern bestellt. Werde mal ein paar Geräte auf das HCL umstellen.
Mich nervt das Thema Z-Wave und IPS ebenfalls seit langem.
Ich habe soviel Schrott-Variablen, die einfach keinen Sinn machen und immer und immer wieder sporadisch erstellt werden.
Neue Geräte einzulernen ist meistens eher ein Krampf.
Die Liste ist lang.
Danke für deine Anregung und teilen der Skripte.

Gruß,
Peter

Gesendet von iPhone mit Tapatalk

Hallo Peter,

bei mir ist jetzt Ruhe mit Zombie-Variablen.

Ich muss nur noch das Abfrage-Skript optimieren und ich will es aufteilen: eines (manuell auzurufen) zum Erstellen der Variablen (kommt kaum vor, da ich mit 64 Geräten den Endausbau erreicht habe) und eines (ständig laufendes) für den Webhook zur Abfrage der Werte „Status“ und „Power“. Ein drittes zur gezielten Abfrage einer einzelnen Steckdose per ID bzw. Steckdosen-Name fehlt auch noch.

Und ich will mal sehen, welche Werte sich aus der HCL-JSON-Antwort sinnvoll verwenden lassen. Die in Fibaro definierten Räume zur Zuordnung der Steckdosen lese ich auch schon einmal am Tag aus.

Ich bin froh, nun alle Geräte und das ZWave-Netzwerk verwalten zu können: Firmwareaktualisierung (habe ich beim Anlegen der Plugs jeweils durchgeführt, wo es nötig war), Backup der kompletten Infrastruktur und im Notfall das Schalten einzelner Geräte (das habe ich jedoch noch nie gebraucht).

Allerdings habe ich mir mit dem HCL nun einen neuen Single-Point-Of-Failure eingehandelt - vom RaZberry-Modul hatte ich ein Ersatzmodul. Hat jemand Interesse an einem RaZberry2?

Hat jemand hier im Forum eine Doku für den graphischen Szenen-Editor von Fibaro? Ich denke an den Webhook-Auslöse-Skripten im HCL kann man noch optimieren.

Viele Grüße aus dem Unterallgäu
Harry

Hallo Harry,

ich habe da auch noch nicht viel gefunden …

Such mal auf der Hersteller Seite nach „/knowledge-base-browse/block-scenes/“.

Das ist zwar recht simple gehalten, aber schon ein Anfang.

Hast Du spezielle Fragen ?

Gruß aus Berlin
Lutz

Hallo Lutz,

Danke für den Tipp.

Es geht mir darum, eine Statusänderung an jeder Steckdose zu erkennen und den Webhook zu triggern.

Momentan brauche ich in der Szene zwei oder-verknüpfte Abfragen: „Steckdose == aus“ oder „Steckdose == ein“

Es wäre schön, das in einer einzelnen Abfrage ähnlich „Steckdose hat Statusänderung“ abzufragen. Dann würden die vielen Szenen (ich habe 64 Geräte) übersichtlicher.

Viele Grüße aus dem Unterallgäu
Harry

Hallo Harry

Ich habe grade mal auf die Schnelle versucht eine grafische Szene für „eine Gruppe“ zu erstellen.

Wenn du eine grafische Szene erzeugst und unter Modul „weitere Module“ anklickst

2020-05-17 21_21_58-Home Center Lite.png

dann werden einem zuerst alle Module angeboten.

Wählst du den „ersten“ aus, bleiben offensichtlich nur noch „typgleiche“ Module (zum auswählen) im Angebot.

Damit kannst du „Gruppen“ bilden, die dann jeweils auf „== AUS“ bzw. „==EIN“ triggern würden.
Ich habe das eben nur beim Spielen festgestellt.

Kannst ja mal eine Test-Szene mit mehreren Wallplugs auf diese Weise zusammenfassen und auf einen Test Virtuellen Modul an den Webhook weitergeben. Da das Script „HCL-Status lesen“ immer alle Module einließt, würde jede einzelne Änderung immer ALLES einlesen.

Ich hoffe es funktioniert so, wie ich mir das vorstelle…
Habe es noch nicht getestet.

Gruß
Lutz

Hallo Lutz,

bevor ich nun im FIBARO-Forum zu suchen beginne, möchte ich hier noch eine (oder zwei) Frage(n) stellen:

Ich habe einen neuen Webhook angelegt und am HCL als virtuelles Modul importiert. Das ist der PUT-Befehl:

PUT /hook/hcl2.php?steckdose=Test HTTP/1.10x0D0x0A0x0D0x0A

Im HCL kann ich dort klicken

hook1.jpg

und in IPS kommt es an

hook2.jpg

und das Skript (Auszug und für hier vereinfacht dargestellt) holt die gewünschten Werte aus dem HCL und speichert es in den Variablen.


$url = $HCL_Url . '/api/devices?id=123';
$json = ""; $resp="";
$resp=file_get_contents($url, 'r');
$json = json_decode($resp, true);   
$status = $json['properties']['value']; 
SetValueBoolean(12345, $status);
$power = $json['properties']['power'];
SetValueFloat(12346, $power);

Soweit alles gut, der Webhook und das virtuelle Modul im HCL scheinen zu passen.

Eine neu angelegte Szene

hook3.jpg

triggert aber nichts. Wo könnte mein (Denk-)Fehler liegen?

Gibt es bei den Szenen eine generelle Einstellung, damit die triggern?

Den Aktiv-Schalter habe ich eingeschaltet,

hook4.jpg

aber es wird einfach nichts ausgesendet.

Zusatzfrage:
Lässt sich der Name des Triggers (= auslösendes Device, hier Test) in einer Variablen an den PUT-Befehl im virtuellen Modul übergeben?

Es wäre schön, wenn Du mir über die letzten Hürden helfen könntest.

Viele Grüße aus dem Unterallgäu
Harry

So nun bin ich vielleicht einen Schritt weiter. Bei der Internet-Recherche bin ich auf den Tipp gestoßen, dass der Autostart aktiviert werden muss.

hook5.jpg

Anscheinend bezieht sich das nicht auf das Starten nach HCL-Reboot, sondern auf den Autostart in LUA.

Ich habe den Haken gesetzt und auch das HCL rebootet. Nun funktioniert es wie erwartet.

Ich hoffe nur, das der HCL-Restart nicht alle paar Tage nötig ist, so wie es in einigen Foren-Beiträgen geschrieben steht.

Welche Erfahrungen habt Ihr mit der Dauer-Stabilität des HCL?

Viele Grüße aus dem Unterallgäu
Harry

Hallo Harry,

schön dass du dir schon weiterhelfen konntest :slight_smile:

Ich wollte Dir noch schnell meine erweiteren Szeneneinstellungen zeigen.
2020-05-21 08_59_01-Home Center Lite.png

„Instanzen“ müssen größer Null und Szene starten „automatisch“ muss gesetzt sein, sonst startet unsere Szene nie.

„Starten wenn HomeCenter 2 startet“ wird bei Timer getriggerten Szenen benötigt.
Die müssen IMMER laufen (automatischer Aufruf alle 1 Sekunde) !!!
Bleibt in unserem Fall also AUS, sonst erhöhst du die Systemlast :rolleyes:

Zum Thema Übergabe von Argumenten an einen Http-Webhook -> IPS-Script:

Hier hatte Bayaro freundlicherweise das hier verwendete Webhook-Script zur Verfügung gestellt:
https://www.symcon.de/forum/threads/28210-IP-Symcon-Wie-kann-ich-2-0?p=267779#post267779

Hier unser Sendestring an den Webhook:

PUT /hook/HCL?SETVarID=54868&SETVarVALUE=0 HTTP/1.10x0D0x0A0x0D0x0A

Dort müsstest Du nur deine weiteren Argumente (die du in gleicher Weise wie die zwei bereits genutzten Argumente an den Webhook schicken willst) auswerten.
Schau Dir das mal in Ruhe an.

Dir und allen Mitlesern einen schönen Herrentag:)
Gruß Lutz

Hallo Lutz,

danke für Deine Screenshots. Die, oder besser den WebHook habe ich im Griff. Das Bayaro-Skript kommt mir bekannt vor, ich glaube das habe ich damals bei meiner Druckersteuerung schon übernommen. Danke unbekannterweise an ihn und alle die hier Code-Schnipsel posten!

Ich falle nur immer wieder auf die Zugriffssteuerung beim HCL-User rein und vergesse die Module freizugeben. Maximale Instanzen habe ich auf 2 gelassen, der Rest ist gleich.

Soweit läuft es bei mir, jetzt kommt die Fleißarbeit, das Ganze für 65 Devices am HCL einzurichten. Schön wäre es, man könnte am HCL auch mit Platzhaltern für den Devicenamen arbeiten, dann bräuchte es nur ein virtuelles Modul und nur eine Szene! Leider ist die Fibaro-Doku etwas sparsam und nur die API-Beschreibung reicht hier nicht. Außerdem kann das HCL kein vollwertiges LUA, aber das HC2 bzw. HC3 wäre etwas überdimensioniert.

Jetzt will ich alle Skripte nochmals prüfen und optimieren.

Meine gesammelten HTTP-Aufrufe und die Abrufstrategie poste ich dann hier.

Viele Grüße aus dem Unterallgäu
Harry

So, hier die versprochen HTTP-Aufrufe die ich nutze:

http://<user>:<password>@<ip-adress>/api/callAction?deviceID=111&name=turnOn               // Gerät 111 einschalten
http://<user>:<password>@<ip-adress>/api/callAction?deviceID=111&name=turnOff              // Gerät 111 ausschalten
http://<user>:<password>@<ip-adress>/api/sceneControl?action=start&id=12                   // Szene 12 starten
http://<user>:<password>@<ip-adress>/api/sceneControl?action=stop&id=12                    // Szene 12 stoppen
http://<user>:<password>@<ip-adress>/api/callAction?deviceID=123&name=pressButton&arg1=1   // virtuelles Modul 123 triggern
http://<user>:<password>@<ip-adress>/api/devices                                           // Module einlesen
http://<user>:<password>@<ip-adress>/api/devices?id=123                                    // Modul 123 einlesen
http://<user>:<password>@<ip-adress>/api/devices?123                                       // Modul 123 einlesen (Kurzform)
http://<user>:<password>@<ip-adress>/api/virtualDevices                                    // virtuelle Module einlesen
http://<user>:<password>@<ip-adress>/api/rooms                                             // Räume einlesen
http://<user>:<password>@<ip-adress>/api/scenes                                            // Szenen einlesen
http://<user>:<password>@<ip-adress>/api/users                                             // User einlesen
http://<user>:<password>@<ip-adress>/api/weather                                           // Wetter-Daten einlesen

Und hier meine „HCL-Strategie“:

[ul]
[li]Einmal in der Nacht hole ich alle Geräte, Räume, Szenen, virtuelle Module und User aus dem HCL ab.
[/li][li]Alle 15 Minuten hole ich die Werte (Status und Verbrauch) und Wetterdaten ab. Falls es neue Geräte gibt, werden die jetzt automatisch angelegt.
[/li][li]Die Hälfte meiner Geräte triggern eine Szene, die den WebHook auslöst, der Status und Verbrauch nur für dieses Gerät beim HCL abfragt und die zugehörigen Variablen in IPS anpasst.
[/li][li]Die andere Hälfte sind Geräte die nicht geschaltet werden (Kühlschrank, usw.), da wird nur der Verbrauch alle 15 Minuten ermittelt (s.o.).
[/li][/ul]
Ich hoffe das hilft dem Einen oder Andere weiter.
Anregungen sind willkommen.

Viele Grüße aus dem Unterallgäu
Harry

Hallo Harry,

ich bemerke grade, dass es eine deutliche Verzögerung (2-4sek. :eek: ) vom antippen eines Dimmer-Lichttaster (z.B. Licht an) bis zum Setzen der Variable in IPS kommt.

Die Verzögerung scheint ursächlich in der Szene des HCL zu entstehen.

Ich forsche hier mal weiter…

Edit:
Mit einem HC2 sind die ober genannten Verzögerungen von Szenen sehr viel kürzer.
Werde wohl darauf umsteigen, trotz des höheren Stromverbrauchs von 14W :eek:

Edit2:
Bin umgestiegen und zufrieden…(BackUp lokal möglich und wesentlich schneller) :smiley:

Gruß
Lutz

Hallo ,

aus Post#30
ich habe meine Scripte auf direkte Aufrufe, wie von lueralba beschrieben umgestellt. Ich hatte mit dieser Variante auch am Anfang gespielt aber es verworfen weil ich keine Verbindung aufbauen könnte.
Ich habe jetzt noch einmal etwas getestet und herausgefunden, dass es an meinen gewählten Passwort lag.
Wichtig für Alle das Passwort darf nicht auf einen Sonderzeichen # enden. Das HCL lässt so keine Verbindung zu - Es geht dann nur über die Curl Funktionen, wo er die Zugangsdaten in base64 benötigt.

aus Post#52

Damit kannst du „Gruppen“ bilden, die dann jeweils auf „== AUS“ bzw. „==EIN“ triggern würden.
Ich habe das eben nur beim Spielen festgestellt.

Habe ich probiert, aber keine zufriedenstellenden Ergebnisse erzielt. Ich habe mehrere Schalter zusammengefasst, aber von 5 Schalthandlungen wurden nur 2 erkannt. Ich finde aber auch nichts dazu in der Doku. Ich teste weiter.

aus Post#58

deutliche Verzögerung in Szene ?

Das kann ich auch bestätigen. Die letzten 3 Monate habe ich in 1sec Takt die Daten geholt. Am Wochenende habe ich die Zeiten hoch gesetzt und über graphische Szene ,Virtuelles Modul und Webhook (in Post #33 von lueralba beschrieben) . aktiv von der Seite des HCL das Script zum lesen der Daten in Symcon angeschoben. Gefüllt mehrere Sekunden Verzögerung. Da ist die 1sec Polling Variante deutlich schneller.
Ein Umstiegt auf das HC2 kommt preislich nicht in Erwägung. Es hängt wahrscheinlich mit der Anzahl der aktiven Szenen zusammen- nur eine Vermutung. Oder doch die nicht zu übige Prozessorlast des HCL’s?
Vielleicht ist es eine Alternative alle Varianten zu kombinieren. Bei wenigen Szenen im HCL geht es gefüllt schnell. Hier kann man über einen separaten Webhook dann nur die Variablen aktualisieren die notwendig sind (beschrieben mit den Magischen Auge Post#4)
Und im Script HCL-Status lesen über eine Case Abfrage die Daten in 2 oder 3 Gruppen teilen (Bsp. Gruppe 1 - 1sec, Gruppe 2 - 60sec, Gruppe 3 - 15min)und diese dann in den entsprechenden Auswertung aktualisiert. Das sollte alles in einen Baustein erfolgen, damit nicht mehrere http Anfragen zur gleich Zeit am HCL landen. Wer weis was dann passiert.
Generell muss ich sagen, das bei mir 1sec Polling Variante ohne Probleme läuft. Das ganze hängt aber auch sehr stark mit den Prozessor und RAM des Rechners, wo Symcon läuft zusammen. Bei mir läuft alles auf einen Rock Pi4 mit 4GB Ram unter Armbian Kernel 4.4
Welche Erfahrungen habt Ihr hier gemacht?

Grüße aus Thüringen
Thomas

Hallo zusammen,

ich bin den Weg nun auch gegangen nachdem die originale Implementation nur noch Frust gebracht hat. Gibt es hier neue Entwicklungen? Ausser IPS_SELF und IPS_SENDER habe ich bisher noch nichts angepasst, die Stati von Schaltern kommen allerdings genau umgekehrt, also Ein=Aus und Aus=Ein :wink:

Beste Grüsse,

Fredrik