Soweit ich weiß → nein.
Wann wollt ihr denn das alte Modul löschen, wenn auch die Steuerung so weit geht?
Wäre ungünstig das vorher zu tun, weil dann der ein oder andere nichts mehr steuern kann auch wenn es noch Beta ist.
Wäre also gut erst mal alle Funktionen zu prüfen und dann das im Modul Store umzuhängen.
Es geht voran 
- Wir unterstützen jetzt alle Geräte (lesend)
- Alle Profile werden übersetzt (Bitte die Gardena Profile vor dem Update noch mal löschen)
- Bewässerung kann gesteuert werden (Die Dauer wird demnächst noch runter zählen
) - Der WebSocket Kanal verbindet sich bei Abbruch automatisch neu
paresy
Mir persönlich fehlt immer noch die Möglichkeit die Instanzen eindeutig zuordnen zu können, bzw. zumindest in der Instanz die Anzeige des Typs und der Seriennummer.
Als Beispiel habe ich einen Sensor der Vorgarten heißt aber auch ein Ventil das Vorgarten benannt wurde. Anlegen tut mir jetzt IP-Symcon eine Kategorie Vorgarten und darunter zwei Instanzen mit dem Namen Vorgarten und eine weitere Instanz mit dem Namen Geräteinformation. Auf den ersten Blick ist so aber nicht ersichtlich für was denn jetzt diese Geräteinformation sein soll, für das Ventil oder den Sensor.
Hier würde ich mir eben eine bessere Zuordnung wünschen.
Die Bewässerung werde ich dann jetzt mal in Betrieb nehmen und das so weit prüfen was geht und was nicht.
ist es geplant mit der Instanz auch gleich noch einen Wochenplan zu ergänzen z.B. bei einem Ventil, oder soll das dann am Schluss per Hand eingerichtet werden müssen?
Bisher nicht. Wir werden aber passende Aktionen / Funktionen anbieten, sodass die Einrichtung sehr einfach sein sollte
paresy
Bei den Ventilen fehlen nach wie vor eine Zuordnung von Icons im Webfront, da sind zur Zeit gar keine Icons zugeordnet worden. Und bei den Geräteinformationen haben auch immer noch nicht alle Variablen ein Icon zugewiesen bekommen.
Ist es möglich den existierenden Zeitplan über die API irgendwie auszulesen? Wenn ich auf Zeitplan aktivieren drücke, dann wird also der Zeitplan der Gardena App aktiviert?
Fehlende Benennung Instanz
Bei mir gibt es einen Sensor der hat den Namen Rosensensor, dieser wird auch mit dem Namen im Konfigurator so aufgeführt. Die Instanz wurde aber ohne passenden Namen erzeugt sondern als Gardena Sensor.
Noch fehlende Methoden
Es gibt zur Zeit noch keinerlei Möglichkeit auf Methoden aus einem Skript zuzugreifen um die Daten auch vollständig abrufen zu können. Es fehlen also Public Methoden in der Instanz um die Geräte Information selber auch abrufen zu können. Es fehlen auch Methoden aus einem Skript zugänglich sind zum Schalten also z.B. Bewässerung für x Minuten einschalten.
Als Beispiel fehlt bei den Sensor nach wie vor die Möglichkeit auch einzusehen wann der Sensor das letzte mal aktualisiert worden ist. Diese Variable existiert zur Zeit einfach nicht und kann auch nicht bei Bedarf zugeschaltet werden um diese Information z.B. in einer Visualisierung nutzten zu können.
Der Wert hingegen wird sehr wohl von der API übergeben. Daher wäre wenn es diese Variablen schon nicht gibt, zumindest sinnvoll das man diese Daten über eine Methode aus einem Skript abrufen kann, um wirklich alle Daten zu erhalten die die API auch liefert bzw. die auch in der Gardena App so angezeigt werden.
Dies sollte jetzt korrigiert sein. Ggf. musst du mal alle Geräte Instanzen löschen. Ebenfalls die GARDENA Profile im Profil-Manager unter Strings - Dann werden beim nächsten Mal neue erstellt bei denen es auch überall Icons gibt.
Die Benennung sollte nun auch besser und klarer sein. Und wir haben die OK/Nicht verbunden Information in den Konfigurator hinzugefügt (sofern vorhanden), sowie auch den internen Geräte-Typ (z.B. VALVE, VALUE_SET) hinzugefügt, damit du die Geräte differenzieren kannst. Ich bin mir aber noch nicht sicher, ob dies für den normalen Nutzer sinnvoll ist oder dies schon zu technisch wirkt.
Funktionen zu den LowLevel Daten werden wir übrigens nicht anbieten.
Aktuell fehlen somit noch die Ansteuerung für den Rasenmäher und die Aktionen, sodass die Module bequem aus Ereignissen/Wochenplänen/Ablaufplänen nutzbar sind. In PHP kannst du die Geräte ja bereits jetzt über RequestAction ansteuern. Dort musst du dies zweistufig machen: a) Die Zeit einstellen und b) die Bewässerung starten.
Bisher haben wir übrigens leider keine API gefunden, um die Bewässerungspläne zu beeinflussen.
paresy
Das wäre wirklich sehr schade. IP-Symcon ist als System dafür bekannt das es auch in der Regel alles auslesen lässt was eine API zur Verfügung stellt, das ist einer der Punkte die IP-Symcon von anderen Systemen deutlich unterscheidet und auch gerade deshalb von Nutzern benutzt wird um alle Information abgreifen zu können die eine API zur Verfügung stellt. Unter anderem auch dann wenn man eine ähnliche Steuerungsoberfläche mit den gleichen Informationen wie die Gardena App erstellen will.
Wo wäre denn das grundsätzliche Problem bzw. woher kommt die Abneigung z.B. alle Daten die nicht angezeigt werden in einem Attribut zu speichern. Für die Power Nutzer, die das dann dennoch abfragen wollen, kann man dann ja einfach das Attribut über eine Methode auslesen. Das erzeugt keinen einzigen API Call mehr, denn die Daten bekommt ja IP-Symcon so oder so über die API zur Verfügung gestellt.
Es wäre einfach sehr Schade wenn man die Information, die einem die offizielle API auch vollständig zur Verfügung stellt und die so oder so übertragen werden und in IP-Symcon ankommen, nicht auch bei persönlichem Bedarf darstellen könnte.
Hallo Fonzo,
wir haben in der Vergangenheit bei eigentlich allen Systemen Entscheidungen getroffen, welche Daten wir anzeigen und welche nicht. Ebenfalls bieten wir für kaum Systeme eine Art „gibt mir alle Rohdaten“ Funktion an. Ich bin mir somit etwas unsicher, ob du an dieser Stelle mehr möchtest, als wir in der Regel anbieten. Sollte der Bedarf dazu tatsächlich von vielen Usern kommen, schauen wir uns dies noch einmal an - falls du unbedingt alle Daten (jetzt) willst, empfehle ich dir eine Register Variable an den WebSocket I/O zu hängen und ein kleines Skript zu schreiben, dass dir dann alle Rohdaten empfängt und auswertet - Denn in IP-Symcon ist ja (fast) alles möglich 
(Was fehlt dir eigentlich konkret? Oder geht es dir irgendwie ums Prinzip, dass du diese Funktion gerne hättest?)
paresy
PS: Es gibt gleich noch ein Update, welches den Rasenmäher/Steckdose ansteuern kann.
PPS: Fehlen noch Aktionen + Doku und dann wollen wir das BSH HomeConnect Modul in Angriff nehmen.
Ich verfolge diese Diskussion sehr interessiert. Und ich kann Fonzo in allen Punkten zu 100% zustimmen, was die Daten betrifft. Ich bin jetzt kein PHP Profi - gar nicht - aber ich hätte gerne Entscheidungsfreiheit.
Wenn ich Entwickler wäre, dann würde ich zu jedem Modul oder was auch immer, die Funktion „stelle alles in einem z.b. Json String“ zur Verfügung was die API hergibt. Was der User, der sich in der Regel auskennt, damit macht, ist seine Sache. Aber es sollte von Seiten des Programmes keine Bevormundung geben, was ich sehen darf und was nicht.
Und ja, da hat Fonzo recht, IPS zeigt sich mir auch als Profi System bei dem alles möglich ist und alle Daten verwendet werden können. Ich sehe gerade IPS und überhaupt die ganze Hausautomation eher als Profi System. Der normale Handyuser wird nie euer Kunde sein, oder der Kunde/User eines jeden anderen Systems. Man muss sich schon sehr tief mit der Materie auseinandersetzen um da was zustande zu bringen. Das zeigen auch immer wieder die Fragen von Neueinsteigern. Da fehlt es vielfach an den Basics, und ich meine jetzt nicht, dass man PHP Programmieren können muss. Das kommt später.
Dass man als Entwickler Vorschläge macht, was vielleicht sinnvoll ist und was nicht, sehe ich ein. Auch verstehe ich die Abneigung nicht, warum man als Benutzer nicht entscheiden darf, welche Variablen angelegt werden sollen und welche nicht.
Dieses, und sorry dafür, blöde Verhalten hat mich weg von Homematic gebracht. Da bist mit einigen wenigen Sensoren mit einer Pro Lizenz schnell am Ende, weil da für einen lächerlichen Temperatursensor gefühlte 100 Variablen angelegt werden, die keiner braucht. Ich wollte nur die Temperatur.
Also bitte überdenkt vielleicht eure internen Vorgaben. Es ist schon in ITIL ein wesentlicher Punkt, Prozesse immer wieder zu Prüfen und gegebenefalls zu überarbeiten, wenn man erkennt, dass es besser geht, oder eben dieser Prozess zu umständlich ist oder einfach nicht funktioniert. Krampfhaft an Dingen festzuhalten, weil es immer so war oder irgendwann vielleicht als sinnvoll erachtet wurde, ist ein Rückschritt.
Ich freue mich schon sehr auf das Gardena Modul, aber wenn ich mir das so ansehe, dann stimmt mich das eher nicht so freudig.
Wie bereits in meinem Post oben vorgestellt, kannst du die Daten am WebSocket zu 100% abgreifen. Solltest du also der Meinung sein, dass irgendetwas fehlt hast du die volle Freiheit. (Und aktuell geben wir alles, was unserer Meinung nach relevant ist, in Variablen weiter).
Probier das Modul am besten einmal aus - denn wir freuen uns sehr über dein Feedback.
parey
Wenn das geht, soll mir das recht sein.
Ich weiß, ich rede mit, obwohl ich es noch nicht gesehen habe, darum habe ich mich auch auf Fonzo bezogen und nur den Teil angesprochen, wo ich denke genug Informationen zu haben.
Sobald die 5.6er draußen ist werde ich es gerne testen.
Genau - aktuell ist diese Diskussion sehr einseitig und vielleicht wirkt es dadurch auch so, als wenn das Modul nichts kann und wir euch keinerlei Informationen liefern. Ich würde mich somit sehr um mehr Tester und mehr Meinung freuen, die das Modul ausprobieren konnten - gerne auch mit weniger technischen Ansprüchen.
@Fonzo Mir ist gerade aufgefallen, dass wir beim Erstellen der Instanz eine Kategorie Ebene zu viel erstellen. Alle Instanzen sollte wie in meinem Bild in eine Bewässerung Kategorie.
Das ist ja auch in Ordnung so das man eine Auswahl trifft, gerade im Bezug auf die mögliche Variablenanzahl. Es ist dennoch für einen erfahrenen Nutzer möglich mit den Boardmitteln die IP-Symcon zu Verfügung stellt Informationen abzurufen oder auch Dinge zu schalten für die IP-Symcon in einer Instanz keine Variablen zur Verfügung stellt. Ein Beispiel ist doch Homematic, hier habe ich einerseits die Variablen die mir IP-Symcon zur Verfügung stellt und auf der anderen Seite die Dokumentation von e-Q3 und die Boardmittel von IP-Symcon zur Verfügung jeden erdenklichen dokumentierten Datenpunkt von Homematic auch auslesen oder beschreiben zu können. Sicher werden das nur fortgeschrittene Nutzer auch machen aber das ist eine der Stärken von IP-Symcon das dies eben geht.
Ich sehe da persönlich keinerlei Unterschied zwischen so was wie Homematic oder Gardena. Auf der einen Seite ist es nachvollziehbar das man sich auf Variablen festlegt, die wohl für die überwiegende Mehrheit der Nutzer auch eine Relevanz haben. Auf der anderen Seite ist es aber für mich dann wiederum nicht nachvollziehbar warum jemand, der das will und braucht, nicht auch Daten, die IP-Symcon so oder so abruft, auch bei Bedarf sich aus IP-Symcon ziehen kann. Das geht ja bei Homematic und anderen Systemen auch.
Ich könnte das durchaus verstehen, wenn es darum geht das man dann wieder einen extra Request stellen muss und das eventuell die Anfragen dadurch unnötig steigen. Dies ist ja aber nicht der Fall, IP-Symcon bekommt diese Daten ja so oder so als ein Paket über den Websocket zugesendet, es wird nur eine Selektion vorgenommen was in Variablen abgelegt wird bzw. angezeigt wird.
Ich fände es daher immer noch wünschenswert hier konsistent über verschiedene genutzte Systeme zu sein, die dann IP-Symcon unterstützt und es dem Nutzer zu überlassen, wie bei Homematic auch, die Daten auszulesen die der Hersteller des Systems auch zur Verfügung stellt.
Letztlich müsste man ja nur die Daten, die nicht in einer Variable abgelegt werden, in einem Attribut zwischen speichern. Dies könnte dann jemand, der das wirklich nutzten will, auch einfach über eine zur Verfügung gestellte Methode auslesen ohne extra einen Request an die Gardena API stellen zu müssen.
Nichts anderes macht man doch mit z.B. mit
https://www.symcon.de/service/dokumentation/modulreferenz/homematic/hm-writevalueboolean/
Hiermit kann ich auch Datenpunkte ansprechen die sich sonst mit einer Variable gar nicht schalten lassen, weil es nicht zu jedem aus IP-Symcon nutzbaren Datenpunkt auch eine Variable gibt.
Auch kann ich in einem Debug Fenster sowohl bei Alexa und auch anderen Systemen sehen was an „Rohdaten“ reinkommt.
Im Zweifelsfall muss man sich dann selber etwas bauen und hängt sich an den Websocket IO von Gardena. Das muss ja aber nun wirklich nicht sein, wenn es auch einfacher gehen würde.
Siehe oben ich nutzte genau aus dem Grund IP-Symcon weil ich eben die Daten die IP-Symcon auslesen kann auch persönlich nutzen kann. Letztlich entstehen dadurch auch die ein oder andere Idee aus dem Forum was man mit den ein oder anderen Daten vielleicht anfangen kann.
Ich sehe das vor dem Hintergrund das man Dinge nicht kompliziert machen muss, wenn es theoretisch auch eine einfachere Möglichkeit geben kann. Die Daten oder auch die Rohdaten kann jemand so oder so einsehen und auch abgreifen wenn er sich an den Websocket hängt. Es ist nur die entscheidende Frage warum muss man das also so kompliziert machen, das dies dann nur ausgewählte Nutzer im Zweifelsfall nutzten können. Dann doch lieber eine Lösung bei der auch ein Nutzer, der nicht so tief sich mit IP-Symcon beschäftigt, im Zweifelsfall optional an so Daten rankommt.
Das werde ich dann auch so machen. Es ist nur wie gesagt nicht ganz für mich nachvollziehbar warum kompliziert wenn es auch einfacher gehen würde. Die 5.6 steht doch unter dem Motto Vereinfachung auch mit dem Ablaufplan.
Genau deswegen nutzte ich es ja. Es ist dennoch eine Frage ob Dinge einfach oder kompliziert gehen. Vielleicht überdenkt ihr das noch mal das man irgendwann auch mit guten Gewissen auch anderen Nutzern gegenüber sagen kann
Denn in IP-Symcon ist ja (fast) alles einfach möglich
Mir geht es nicht um Prinzipien sondern um eine ganz konkrete Vorstellung das ich die Daten die ich in der Gardena App angezeigt bekomme eben in einer Visualisierung anzeigen kann mit Daten die von IP-Symcon kommen, denn ich will eben nicht mehr immer die Gardena App nutzten müssen, aber dennoch die Information zur Verfügung haben, die ich eben in der Gardena App auch sehe.
Also abgesehen von Winterschlaf und Einpflanzanleitung eben die Infomation, die ich in der Gardena App einsehen kann.
Ich fände s wie gesagt gut wenn eine Dokumentation vielleicht auch mit konkreten Anwendungsbeispielen als PDF zur Verfügung stände bzw. auch auf der Seite von Symcon. Irgendwie auf Github zu verlinken macht einen weniger professionellen Eindruck, vor allem für mögliche Neukunden
Konfigurator Fehler
Warning: Profil mit dem Namen #Gardena.ValveSet.Commands existiert nicht in C:\ProgramData\Symcon\modules\Gardena\Gardena Valve Set\module.php on line 50
Und der Typ müsste noch im Konfigurationsformular übersetzt werden.
Hi Fonzo,
schau dir am besten einmal an, was auf dem WebSocket Kanal wirklich kommt. Du wirst sehen, dass wir wirklich fast alles anzeigen. Die App scheint leider eine andere Quelle für weitere Informationen zu haben. Sofern du die Daten irgendwie in den JSON Paketen findest - sag uns bitte bescheid. Denn dann sind diese bestimmt für alle Interessant.
Sofern mir korrekt bekannt zeigen wir aktuell nur die Seriennummer nicht in einer Variable an und die Zeitstempel der übermittelten Werte. (Diese sind aber wie immer in der Variable als VariableUpdated drin, sofern ihr diese per IPS_GetVariable abfragen wollt).
Hier noch ein Bild mit den Daten des Rasenmähers
Und hier vom Sensor:
paresy
Öffnungsdauer fehlt noch ein Icon wie z.B. eine Clock
Hi Fonzo,
hast du zufällig dafür aus der App die entsprechenden Namen zur Hand?
paresy
Korrigieren wir. Beim Rasenmäher scheinen auch noch zwei zu fehlen.
paresy