Ja, eine erste Version ist jetzt online: GARDENA smart system — IP-Symcon :: Automatisierungssoftware
paresy
Da steht an einer Stelle Gerdena statt Gardena
Wir haben die Ursache gefunden und ich warte aktuell auf Gardena, wie wir das Problem lösen, da es eigentlich ein Fehler in deren Infrastruktur ist.
Zum nächsten Update korrigiert.
Die Sensoren melden sich über den WebSocket Kanal automatisch sobald es neue Daten gibt. Mir wäre nicht bekannt, dass es einen API Endpunkt gibt, bei dem man den Sensor auffordern könnte neue Daten zu senden.
Hat Fonzo ebenfalls gewünscht. Aktuell gibt es also 2 Votes 
Dies ist noch ein generelles Problem bei String Assoziationen, welches wir aktuell auch bei Home Connect haben. Ich spreche da mal zeitnah mit @Dr.Niels, wie wir uns dies Vorstellen und welche Lösungen hier sinnvoll wären.
Das geht übrigens ganz einfach mit:
// Für 5 Minuten gießen
RequestAction($id_von_ValveDuration_variable, 5 /* Minuten */);
RequestAction($id_von_ValveControl_variable, 'START_SECONDS_TO_OVERRIDE');
// Schließen
RequestAction($id_von_ValveControl_variable, 'STOP_UNTIL_NEXT_TASK');
paresy
Drei 
Dies ist ein Text damit ich die mindestzeichenanzahl erreiche 
2 „Gefällt mir“
Naja, ist ja auch ein geschlossener Beta Test. Ihr könnt also entweder das Feedback von drei Beta Testern annehmen und darüber nachdenken, oder darauf warten wenn das Modul öffentlich ist, das dann öffentliche Anfragen oder Support Anfragen deswegen kommen und das dann später vielleicht doch ergänzen.
Definiere einfach,
Als langjähriger Nutzer mag das für mich und auch viele andere, die mit IP-Symcon vertraut sind, noch einfach sein und aus Eurer Sicht so oder so, weil Ihr die eigene Software wohl kennen solltet.
Ist das für einen „Gardena“ Nutzer, der das mal auf einen Schalter legen will auch einfach?
Aus meiner persönlichen Sicht nicht, da man erst mal wissen muss das da
START_SECONDS_TO_OVERRIDE
und
STOP_UNTIL_NEXT_TASK
eingetragen werden muss. Woher soll das jemand einfach so wissen?
Ansatzweise noch inuitiv wäre
RequestAction($id_von_ValveControl_variable, true);
weil das vielleicht ein Nutzer von anderer Stelle her kennt, das geht ja aber in dem Fall nicht.
Das Problem bzw. die Abneigung einfach zwei public Methoden anzubieten, die man aufrufen kann verstehe ich zwar persönlich immer noch nicht, aber ihr könnt ja noch mal darüber nachdenken, nicht aus Eurer persönlichen Sichtweise als Programmierer, sondern sich wirklich mal in jemand als Kunde und Nutzer reinzuversetzen der IP-Symcon seit 1 Woche nutzt.
Danke, paresy! Könnte man das nicht bei Gardena anregen, einen solchen Endpunkt zur Verfügung zu stellen? Ansonsten ist die Info nicht viel wert, da teilweise erst nach mehr als 3 Stunden automatisch aktualisiert wird (so etwa der Feuchtewert gerade bei meinem Sensor)…
Es macht aber auf der anderen Seite auch keinen Sinn den Wert öfters abzufragen. Die Funktion ist in der App ja auch nur für besondere Fälle bzw. um das mal im Einzelfall anzufordern. Der Sensor ist ja Batterie betrieben, daher sendet dieser eben nur in gewissen Zyklen Werte sonst wäre die Batterie ruck zuck leer.
Du bekommst ja in der Regel alle Werte in IP-Symcon mit, auch die Gardena App bekommt nicht öfters aktuelle Werte vom Sensor geschickt.
Das einzige Manko ist s.o. das Du zwar mit der APi den Zeitstempel der letzten Datenübertragung übermittelt bekommst, aber Symcon diesen Wert, obwohl er übermittelt wird, nicht abgreifen lässt per Methode, indem der Wert z.B. in einem Attribut gespeichert wird oder optional dazu noch eine Variable anbietet. So weis man also zumindest in IP-Symcon nicht wann der Sensor eigentlich wirklich das letzte mal Daten aktuell gesendet hatte. Eine Anzeige wie in Deinem Bild ist also leider so mit einer Visualisierung die auf Daten von Symcon beruht leider nicht möglich.
Es sei denn Symcon gibt sich doch noch einen Ruck und bietet den Wert an auszulesen bzw. in eine Variable zu schreiben, mehr als sagen, das wir gerne diesen Wert nutzten und gerne anzeigen würden, wie in der Gardena App auch, können wir man ja nicht.
Es geht nicht darum, den Wert laufend manuell zu aktualisieren. Es reicht, wenn dies unmittelbar nach der Bewässerung möglich wäre (schade ist, dass das bei Gardena nicht automatisch passiert; man bewässert ja idR nur max. einmal täglich) oder etwa nachdem es geregnet hat. Wenn dies jeweils um 20 Uhr der Fall ist, nutz es nichts, wenn der Wert sich erst automatisch aktualisiert, wenn ich schlafe. Dafür kann er ja auch in der Gardena-App manuell aktualisiert werden. Um zu vermeiden, zweigleisig fahren zu müssen, wäre es einfach zielführend, wenn solche grundlegenden Möglichkeiten auch per IPS bereit gestellt werden könnten.
Gerade in einer Automatisierungsplattform sollte es möglich sein, schauen zu können, ob eine Aktion reicht (Feuchte ausreichend) oder ob nachgelegt werden muss (ergänzend bewässern)…
Da ist eher der Zeitstempel von weniger Relevanz, da ich zumindest die Möglichkeit habe, mir eine entsprechende Variable selbst anzulegen.
Insgesamt wäre aber beides absolut wünschenswert.
Ganz so einfach ist das dann auch nicht, weil Du eben zur Zeit keine Methode zur Verfügung hast um diese Daten einfach abzurufen und in eine eigene Variable zu schreiben.
Stattdessen kannst Du Dir höchstens ein Konstrukt bauen und Dich an den IO mit einer Registervariable und einen weiteren Skript zu hängen um an diese Daten überhaupt ran zu kommen.
Für die Bodenfeuchte habe ich mir eine Integer-Variable (Profil Unix) erstellt, die zu und mit dem Zeitpunkt gefüttert wird, in dem sich die Variable Bodenfeuchte geändert hat. Den hole ich mir über IPS_GetVariable… Dies ist jeweils der Zeitpunkt, zu dem das auch in Gardena passiert (schon getestet).
Das funktioniert so aber nicht bzw. den Wert den Du da hast, stimmt nicht mit dem Wert überein wann der Sensor das letzte Mal Daten gesendet hat, siehe auch hier:
Die API übergibt die Werte ja zeitgleich an IP-Symcon mit einem zugehörigen Zeitstempel, wann welcher Wert vom Sensor aktualisiert gesendet wurde. Der Zeitpunkt wann IP-Symcon diese Daten dann aber abspeichert stimmen nicht mit dem Zeitpunkt wann der Sensor bestimmte Daten gesendet hat überein.
Das einzige was Du auf diese Weise also anzeigst ist der Zeitpunkt an dem IP-Symcon die Daten abgespeichert hat, nicht aber der Zeitpunkt der letzten Datenübertragung des Sensors.
Nach meiner mehrfach verifizierten Erfahrung erfolgt die Aktualisierung des Zeitpunktes der (automatischen wie auch manuellen) Aktualisierung des Wertes Bodenfeuchte in IPS zeitgleich (bzw. direkt danach, also nahezu zeitgleich) mit dem in der Gardena-App und stimmt daher jeweils und immer überein…
Die „Letzte Übertragung anzeigen“ kann jetzt in jeder Instanz aktiviert werden. Das Update dazu ist jetzt im Store online.
Zu den RequestAction / Befehl hinzufügen Problem haben wir uns konzeptionell noch mal ans Reißbrett gesetzt und werden diese wie folgt überarbeiten:
a) Der „Befehl hinzufügen“ Dialog wird nicht mehr die kryptischen IPS_RunScriptText Befehle einfügen, sondern die echten „RequestAction“ Befehle (oder passende je nach Aktion), wodurch die Leserlichkeit verbessert wird und wir aber nicht mehrfachen Aufwand haben für Alias Funktionen wie GARDENA_CloseValve.
b) Wir werden im Skript Editor bei RequestAction mehr Kontext-Informationen anzeigen, wie wir dies bereits bei den ObjektIDs tun. D.h. wenn dort ‚STOP_UNTIL_NEXT_TASK‘ wird hinten dran noch eine Kommentar ‚Schließen‘ angezeigt, sodass klar ist, was RequestAction tun wird.
c) Der Skript Editor wird bei STRG+Space ebenfalls eine Liste von Möglichen Werten anzeigen, sobald man RequestAction nutzt. D.h. alle Werte bei den String Profilen (wie z.B. STOP_UNTIL_NEXT_TASK) würden dann angezeigt (mit Beschreibung), sodass eine Auswahl schnell möglich ist und man sich dies nicht mehr merken muss. Dies hilft auch bei anderen Profilen wie z.B. ~ShutterMoveStop, bei denen man sich bisher 0,2,4 merken musste.
paresy
1 „Gefällt mir“
Ich habe ein kleines Problem mit dem Update.
Da das eine Symbox ist weis ich auch nicht so recht was ich da jetzt machen soll. Symcon beenden und dann Modul löschen und neu probieren zu installieren?
Selbst wenn ich das löschen wollte auf einer Symbox von Hand mit WinSCP in welchem Verzeichnis finde ich denn das Modul?
Der Fehler sollte eigentlich nur kommen, wenn du auf einem Kanal bist, den es nie gab…
Magst du mal die Ausgabe von SC_GetModuleInfoList($storeControlID) posten? Dann können wir mal schauen, auf welchem Kanal du angeblich bist.
76 =>
array (
'BundleID' => 'de.symcon.gardena',
'Channel' => 0,
'ReleaseID' => 0,
'LibraryID' => '{00361A9B-1752-5EB6-0534-97E4DB98CD80}',
'Error' => '',
),
Wie gesagt ich würde ja Symcon stoppen, Modul löschen und neu installieren.
Nur weis ich bei einer Symbox nicht wie das Geht da finde ich nur Neustart von Symcon aber kein beenden und wo das Modul im Verzeichnis baum zu finden ist um es zu löschen weis ich auf einer Symbox auch nicht.
Ja, angeblich bist du auf Stable, was es ja nicht gibt. Das kommt wahrscheinlich, weil das Modul nicht in den Settings steht, aber im Store-Ordner.
Du kannst das Modul aber sonst via SC_DeleteModule($storeControlID, ‚de.symcon.gardena‘) löschen und dann neu installieren.
Das hat so weit funktioniert.
Wenn Du Dir die Daten mit der API übertragen werden anschaust sind die Werte nicht zeitgleich. Aber Du hast ja jetzt mit der neusten Version die Option mit Letze Übertragung anzeigen die von der APi übergebenen Werte anzuzeigen. Dann hast Du auch die Möglichkeit das mit den Werten die Du bisher erfasst hast zu vergleichen.