jein. Der Fehler ist klar, ich greife auf ein Feld im json-array zu, das eigentlich immer da sein muss/müsste.
Das abzufangen ist kein Problem, aber ich wüsste gerne, was der Grund ist. Dazu müsstest Du mir, wenn es geht ein Debug der entsprechenden Instanz schicken, in dem steht drin, welche Daten Hydrawise schickt.
Ist dir die Erstellung eines solchen Debugs geläufig? Ich brauche den Debug Instanz der Zone, die zu diesem Zeitpunkt aktiv war und die diesen Fehler geworfen hat. Den Debug bitte direkt per Mail schicken (demel42@web.de)
Meine Vermutung:
ich greife hier die Wassermenge ab, die in einem Zyklus verbraucht wurde. Muss aber gestehen, das ich gar nicht weis, ob dieses Feld kommt, wenn man
a) keine zugeordneten Wasseruhr hat
b) oder die Zone dieser Wasseruhr nicht zugeordnet ist
Es kann aber auch einen ganz anderen Hintergrund haben …
Für einen Fix: hast Du über den Modulstore oder „klassisch“ über Kern -> Modules installiert?
Gruß
demel
ps: ich sehe, es ist über den Modulstore installiert
Erlaubt mir eine kurze Frage, da ich mich gerade mit der Idee beschäftige auch ein Hunter-System anzuschaffen:
Lässt sich jeder Hydrawise-Controller auch ohne Cloud steuern?
Also HC, HPC und HCC? Oder nur der HCC?
nein, geht immer über die Cloud. Im Prinzip wird regelmässig das Programm für die nächsten Tage berechnet und dann auf den HC-6/-12 geladen. Dh. die Steuerung der Ventile funktioniert auch ohne Internet.
Wenn man aber die Ventile (Zonen nenne die das) ansteuern möchte, geht das immer nur über die Cloud, die dann den Befehl an den HC weiter schickt.
Die Cloud ist kostenlos im Home-Plan und kostenpflichtig im Enthusiast-Plan. Unterschied ist im wesentlichen, das man im Home-Plan nur bestimmte Wetterstationen auswählen kann und im Enthusiast-Plan jede beliebige aus Weather-Underground
kurze Frage, bestimmt auch für die Öffentlichkeit interessant.
Ich hatte eine Netzwerkanpassung, in ein anderes Subnetz. Hab im Router die Mac des Hunter-Controller auf eine IP geschickt. Seit dem bekomme ich in IPS zwar keine Fehler wegen dem Modul und kann auch die Kreisläufe per manuellem Button starten, aber es aktualisieren sich keine Variablen und auch das Datum „letzte Kommunikation“ bleibt unverändert seit 17.02.2020. Netzwerkverbindung besteht aber. Wo kann ich drehen, dass alle Daten wieder aktualisiert werden. Eine IP-Adresseingabe konnte ich im Modul nicht finden.
Gruß oekomat
edit: im Controller selbst hab ich eine Wlan Verbindung und auch die richtige IP kommt an, im Onlineportal stimmt auch alles
die API 1.4 ist deutlich abgespeckt (die nennen das „bereinigt“) worden, d.h. es fehlen die Angabe
Sensordaten (also Wasserverbrauch) :-((
Information Bewässerungszeit und Wassereinsparung (pro Woche) etc
Wettervorhersagen
da zudem die bisherigen Informationen fehlen zu „suspended“ und „running“ muss ich erstmal schauen, wie ich den Zustand einer Zone aus den Daten herauslese.
es gibt keine Information mehr zu dem vorigen Bewässerungslauf - ich muss schauen, ob ich das simulieren kann
es sind nicht mehr ein HTP-Request sonder zwei notwenig, um an die Informationen zu kommen
Ich habe mit dem support konferiert, war wie meistens wenig zielführend, konnte aber die erforderlichen Änderungen (um wieder einen vergleichbaren Leistungsumfang zu haben) an das Produktmanagment schicken. Dauert bis zu 30 Tage, bis die Antworten.
Parallel dazu hat paresy die angeschrieben, weil es angeblich eine oAUth2-basiere Schnittstelle gibt, vielleicht bietet die ja mehr, Doku war nicht zu bekommen.
Grundsätzlich habe ich einen Teil wieder am laufen, es fehlen aber noch die Zonen …
Die Befehle (also Zone ein/aus etc pp) sind unverändert und funktionieren weiterhin.
ich bin von dem Modul auf den Store gewechselt und jetzt tut garnichts mehr. Schon die Konfiguration geht nicht mehr (siehe angehängter Screenshot). Irgendeine Idee?
ja, das liegt daran, das sich die API geändert hat und das Modul greift auf (relevante) Informationen zurück, die nicht mehr da sind.
bei mir klappt der HydrawiseConfigurator und der HydrawiseController schon wieder (natürlich eingeschränkt mangels früher vorhandener Daten). Es fehlt aber noch die HydrawiseZone, die ist allerdings schon etwas komplexer, weil ich versuchen muss bestimmte Daten, die es früher gab aus anderen Daten zu gewinnen.
Ich weis nicht ganz, ob ich das über Ostern hinbekomme, aber das wäre mein Ziel.
Ist natürlich jetzt noch etwas schwierig zu testen, weil ich die Bewässerung noch nicht wirklich laufen habe und somit nur eingeschränkt testen kann.
HydrawiseSensor wird zwar weiter bestehen bleibet, ist aber mangels Information über den WaterFlow ohne wirklich Funktion.
Wenn Du möchtest, der aktuelle Stand meiner Entwicklung ist nun auf GitHub verfügbar.
Da das Modul ja so oder so nicht mehr funktioniert, habe ich diese unvollständigen Zustand einfach unter dem master-Branch veröffentlicht.
ich habe das Modul soweit überarbeitet, das es erstmal wieder läuft, muss aber noch weiter beobachten/testen, ob alles funktioniert
die Anpassung an die neue API-Version 1.4 hat viele Einschränkungen gebracht
die API liefert keine Information mehr über:
[ul]
[li]über den Wasserverbrauch eines Bewässerungszklus[/li][li]die letzte Bewässerung (Zeitpunkt und Dauer), wird nun selbst ermittelt[/li][li]den Endzeitpunkt der Suspendierung einer Zone[/li][li]Suspendierung einer Zone mit einer Dauer kürzer als (vermutlich) einer Woche wird nicht als Suspendierung gemeldet[/li][li]die wöchentliche Bewässerungszeit und Wassereinsparung[/li][li]das aktuelles Wetter und Vorhersage[/li][/ul]
Wirklich schade. die API war schon vorher ziemlich mäßig, aber nun ist sie noch dazu Funktionsreduziert.
Dafür, das die API offiziell ist, ist sie grottenschlecht dokumentiert, existierende Felder im Datensatz sind nicht erwähnt, die vorhandenen Erklärungen zu Feldern sind „überschaubar“ und nicht wirklich korrekt.
:mad: Genug ausgekotzt
Also wer testen möchte: Modul ist im Git aktualisiert und steht auch als Beta zur Verfügung.
vielen Dank für das Update, ich habe im Modulstore auf Beta gestellt und in IPS die aktuellen Variablen hinterlegt. Die Steuerung funktioniert soweit. Mir ist aufgefallen, dass die Berechnung der Zeiten nicht ganz hinkommt. Beispiel. Hab als Vorauswahl auf 15 min gestellt und nach 7 min man. beendet. „Dauer der letzten Bewässerung“ erhöhte sich um 1 min, „Bewässerungsdauer heute“ erhöhte sich um 2 min. Die „letzte Nachricht“ wird auch gelöscht, wenn sich die Variablen aktualisieren.
Ich denke mal mit wärmeren Temperaturen werden auch mehr Leute Ihre Anlagen einschalten:cool:
Hmm, das ist merkwürdig. Die Tageswerte entstehen durch Addition der Einzelwerte (und die sind auf Minuten gerundet) … wie da unterschiedliche Zahlen rauskommen, kann ich mir im Augenblick nicht vorstellen.
Das mit der Abbruch Abe ich auch gerade probiert, hat bei mir funktioniert. Kannst Du das bitte weiter beobachten, ggfs einen ausreichend großen Debug der entsprechenden Zone (also den ganzen Zeitraum von einige Minuten vor dem Start bis einige Minuten nach dem Abbruch) und mir schicken.
das war auch vorher so. mit fehlt die Idee, wann ich das sonst wieder löschen sollte, denn auf Dauer stehen zu lassen ist ja auch doof. Ich hatte mal überlegt, das nach einigen Minuten zu löschen, habe das aber mangels Bedarf noch nicht implementiert.
Eine andere Idee hatte ich da nicht.
Hallo,
das ist komisch, bei mir kommen keine Fehler (und die Version ist bei mir schon ein paar Tage alt).
ich habe die Stelle entfernt, was sowieso nur ein Debug-Statement.
Allerdings würde mich schon interessieren, wie deine Daten aussehen - da ja immer noch viel Raterei in der APi notwendig ist, muss ich natürlich viel davon sehen.
Kannst du bevor du updatest den Debug vom Controller mal aktiveren (bitte Limitierung ausreichend erhöhen) und bei der nächsten Zone schauen, ob es rumst und mir in dem Fall den Debug mailen und die Zonen nennen?
Genug ausgekotzt 
