Ich starte gerade mit der Entwicklung eines neuen, Lokalen Moduls für das LinkTap Systems. Die Kommunikation geschieht über MQTT. Ich benutze die Dokumentierte MQTT Schnittstelle von LinkTap.
Bleibt also am Ball. Es gibt bald was zu testen. BETA Anweisungen
Kurze Wasserstandsmeldung!
Es geht voran. Hatte kurzweilig einen Loop of Death im Mqtt Broker ausgelöst, da linktap das Senden und empfangen teils interessant gelöst hat.
Aber man schafft schon Wasser für eine definierte Zeitspanne zu starten. Wasserfluss abbrechen und eventuelle Alarme zurücksetzen. Noch paar grundsätzliche Sachen und die paar quick und dirty Ansätze bereinigen und wir können in die beta. Eventuell hat ja auch jemand 2 oder mehr linktaps.
Ich will mir zwar irgendwann noch den 4er holen aber dafür muss der Garten entsprechen geändert werden . Währe interessant ob ich genug Filtere um nur das angelegte Tap zu steuern/anzuzeigen. Bzw. Jedes Tap für sich…
Gruß Dennis
Hallo Zusammen,
es ist soweit. Wir starten in die BETA!
Bitte, da es noch BETA ist, exakt nach LinkTap suchen. Das Modul mit dem Hinweis in der Beschreibung das dieses Lokal über MQTT läuft ist das richtige.
Vorbereitungsmaßnahmen:
ruft die Webseite eures Gateways auf und setzt die mqtt Einstellungen.
In der LinkTap App nach der Seriennummer eures Bewässerungsgerät suchen.
wir brauchen nicht die Gateway Nummer sondern je nachdem welches Gerät und wie Ihr es benannt habt die Endgeräte Nummer. 16 Stellen soll sie sein. Bei mir kommt noch -xxxx dahinter. Das weglassen.
Im Modul alle Parameter setzen wie vorher im Gateway eingestellt bzw. in der App ermittelt.
vielen Dank für das Modul. Ich habe es mal parallel installiert, da ich die MQTT-Sache schon länger in Gebrauch habe mit 2 LinkTap-Gateways. Hier meine ersten Feststellungen:
Gesamtdauer lässt sich nicht „klein“ genug eistellen. Eine Bewässerung über mehrerer Stunden erscheint eher unrealistisch, daher wäre eine Auswahl für Minuten sinnvoller (ich habe zB von 2 bis 180 Minuten).
Wenn ich mit RequestAction die Dauer in der Sofort-Bewässern-Variablen setze (z.B. bei Bewässerung über einen Wochenplan), beendet die Bewässerung immer nach wenigen Sekunden wieder.
Letzte Befehlsantwort wird nicht gesetzt.
Update-Intervalle sind zu lang. Zumindest während der Bewässerung könnte regelmäßig (z.B. jede 30 Sek.) aktiv abgefragt werden (cmd 3).
Zur nachträglichen Kontrolle habe ich bei mir noch eine History-Variable eingerichtet, in der die letzen 20 Bewässerungsstarts und -Beendigungen dokumentiert werden. Das könnte ggf. ebenfalls eingebaut werden.
Hi @CarnivoreD,
vielen Dank fürs Feedback. Genau deswegen haben ich so eine Frühe Version veröffentlicht, um auch paar Ideen einzusammeln und eine Diskussionsgrundlage zu schaffen.
Hier zu deinen Anmerkungen:
Gesamtdauer lässt sich nicht „klein“ genug eistellen. Eine Bewässerung über mehrerer Stunden erscheint eher unrealistisch, daher wäre eine Auswahl für Minuten sinnvoller (ich habe zB von 2 bis 180 Minuten). → Alles klar. Ich werde mehr Assoziationen hinzufügen.
Wenn ich mit RequestAction die Dauer in der Sofort-Bewässern-Variablen setze (z.B. bei Bewässerung über einen Wochenplan), beendet die Bewässerung immer nach wenigen Sekunden wieder. → Wie Du bereits selber festgestellt hast sind es Sekunden.
Letzte Befehlsantwort wird nicht gesetzt. → Das stimmt. Ist noch nicht implementiert. Ich hatte einen Cycle of Death der meinen MQTT Broker in die Knie gezwungen hat und somit hatte das nicht in die BETA geschafft.
Update-Intervalle sind zu lang. Zumindest während der Bewässerung könnte regelmäßig (z.B. jede 30 Sek.) aktiv abgefragt werden (cmd 3). → Aktuell nutze ich das was das Gateway von sich aus meldet. Ich hatte noch nicht Validiert wie schnell der Status automatisch vom Gateway gesendet wird. Werde also noch einen Einstellbaren Timer Hinzufügen der das Gateway dann in Intervall den Status entlockt.
Zur nachträglichen Kontrolle habe ich bei mir noch eine History-Variable eingerichtet, in der die letzen 20 Bewässerungsstarts und -Beendigungen dokumentiert werden. Das könnte ggf. ebenfalls eingebaut werden. → Frage hierzu. Hast Du dort ein Array hinterlegt oder wie hast Du dir das aufgebaut? Finde ich in der Tat interessant.
Ich habe das mal versucht zu extrahieren und dazu eine Test-String angelegt:
$stro = GetValue(12345); // Test-String
$strn = ("Wasser an am ").date("d.m.Y").(" um ").date("H:i:s")."\n";
// Zusammenfügen alten und neuen String mit ältestem am Anfang
$strg = $stro . $strn;
// Aufteilen String in ein Array von Zeilen
$lines = explode("\n", trim($strg));
// Überprüfen, ob mehr als 25 Zeilen vorhanden sind
if (count($lines) > 25)
{
// Entfernen der ersten Zeile im Array
array_shift($lines);
}
// Zusammenfügen des Arrays zurück in String
$string = implode("\n", $lines) . "\n";
SetValue(12345, $string);
Auslöser ist die is_watering-Variable. In Abhängigkeit von ihrem Wert ist
$strn = ("Wasser an am ").date("d.m.Y").(" um ").date("H:i:s")."\n";
oder
$strn = ("Wasser aus ").date("d.m.Y").(" um ").date("H:i:s")."\n";
Noch ein weiterer Vorschlag:
Manchmal folgt einem Befehl keine Schaltung, so dass ich bei mir eingebaut habe, dass in diesem Fall der Befehl wiederholt wird. Das sollte sich in einem Modul sogar einfacher implementieren lassen, da hier sicherlich gewartet werden kann, bis eine Variable sich ändert (z.B. die is_watering beim Einschalt-/Auschaltbefehl), und wenn dies nicht innerhalb einer bestimmten Zeit passiert (z.B. 30 Sekunden) der Befehl wiederholt wird.
Moin Zusammen,
nächste Beta ist Raus. Wichtig: die letzten 2 Topics vom Gateway müssen auch noch eingestellt werden.
Man kann jetzt in Sekunden einstellen wie oft die Werte Aktualisiert werden sollen.
Habe jedoch beobachtet das trotz 5 Sekunden Aktualisierung das Gateway nur alle 15 Sekunden veränderte Werte sendet.
Befehlsantworten kommen jetzt auch.
Hoffe es geht weiterhin in die richtige Richtung.
@CarnivoreD Vergangene Bewässerungen kommt auch noch
TXT: 13.07.2024, 16:03:47 | RequestStatus | Send Status Request to LinkTap Gateway
TXT: 13.07.2024, 16:03:47 | GetPackageForDownlink | Data to send to LinkTap {„DataID“:„{043EA491-0325-4ADD-8FC2-A30C8EEB4D3F}“,„PacketType“:3,„QualityOfService“:0,„Retain“:false,„Topic“:„/linktapDT/dev_cmd“,„Payload“:„{"cmd":3,"dev_id":"28169428004B1200","gw_id":""}“}
TXT: 13.07.2024, 16:03:47 | Received Data from Parent | {„DataID“:„{7F7632D9-FA40-4F38-8DEA-C83CD4325A32}“,„PacketType“:3,„Payload“:„{"cmd":3,"gw_id":"60B8552E004B1200","ret":3}“,„QualityOfService“:0,„Retain“:false,„Topic“:„/linktapDT/dev_cmd_ack“}
TXT: 13.07.2024, 16:03:47 | Received Answer from LinkTap | {„DataID“:„{7F7632D9-FA40-4F38-8DEA-C83CD4325A32}“,„PacketType“:3,„Payload“:„{"cmd":3,"gw_id":"60B8552E004B1200","ret":3}“,„QualityOfService“:0,„Retain“:false,„Topic“:„/linktapDT/dev_cmd_ack“}
Über den MQTT-Broker werden alle Werte verarbeitet, nur in der Instanz kommen sie nicht an…
Sehr Interessant…
Hatte vermutet das es daran liegt das ich mein Modul fleißig upgedatet habe ohne mal eine Instanz von neuem anzulegen aber, nach nicht mal 15 Sekunden (Ich lass alle 15 Sekunden aktualisieren) kamen alle Werte.
Hast Du im Gateway diese Einstellung gewählt?
Die Topics Stimmen alle?
Es liegt daran, dass ich in den Gateways bei den MQTT-Einstellungen unter Uplink „All devices’ status are grouped and published to one topic.“ eingestellt habe. Ich habe das mal kurz geändert, da wurden die Modul-Instanz-Variablen aktualisiert.
Ich habe es jedoch wieder zurückstellen müssen, da mein „produktives“ LinkTap-System sonst nicht läuft… Vor dem letzten Update hat es mit dieser Einstellung allerdings auch mit dem Modul funktioniert.
Okay gut,
Dann weiß ich warum. Ich filtere für jede Instanz seit dem letzten Update auf die Device ID.
Ich werde die Tage mal die Filterung wieder verallgemeinern wie vor dem Update.