Bin weiterhin mit dem Support im Austausch, noch keine finale Aussage zur API V1.
Aber kurze Frage: auf Github steht: Bei Wunsch können die Daten des go-eChargers auch via MQTT empfangen werden. Entsprechend ist auch diese Option bei Bedarf zu aktivieren.
Ist das ein oder (V1 oder MQTT) oder wird die V1 auf jeden Fall benötigt? Sonst richte ich MQTT ein und gut.
Das Modul kann zwar auf MQTT reagieren, aber alle Funktionen zum steuern gehen über die HTTP-API. Insofern ist die API V1 aus meiner Sicht notwendig.
Aber was haben die denn da schon wieder getrieben, wenn die API V1 bei dir nicht angeboten wird.
Ich wollte ja immer mal ein neues Modul nur auf der API V2 aufsetzen, bin da aber nie zu gekommen, und mit der API V1 + V2 Kombi hat es ja bisher auch immer funktioniert…
hab eben die Bestätigung vom Support bekommen: die API V1 gibt es nur bis HW-Version 3, ab Version 4 nicht mehr. Die Pro ist HW4 und unterstützt damit die API V1 nicht mehr.
Ja, wäre auch das nächste - Abrufen per MQTT, steuern per ModBus. Nur die gute Vorarbeit von Coyote hätte mir da einiges an Arbeit erspart.
BTW: eine reine API-V2-Lösung läuft bei mir auf dem Cerbo (Victron-Steuereinheit). Vielleicht reicht das schon, um die Steuerung zu realisieren. Sprich MQTT-Steuerung über den Cerbo, denn der ist schon eingebunden.
das Problem ist, das die API V2 nicht abwärtskompatibel ist.
Ich habe mir das mal angeschaut. Evtl. könnte ich dem Modul beibringen, nur die V2 zu nutzen. Zum Lesen dürfte dies, bis auf Awattar/dynamische Ladepreis-Werte gehen (da ist die V2 Doku eh etwas unscharf/falsch).
Beim Setzen zum Charger müsste ich schauen, ob das dann alles klappt (da habe ich so meine Überraschungen mit der Go-e erlebt).
Muss mal gucken, ob ich da am WE zu komme und dann ggf. einen “Nur API V2 Switch” anbieten kann.
Ich häng mich hier mal mit rein. Meine go-e Charger Pro wurde am Freitag auch endlich vom Elektriker installiert. Jetzt hänge ich auch gerade an der Einrichtung der Wallbox in IP-Symcon
Also wenn du irgendwelche Infos brauchst, helfe ich gerne. Hab ja entsprechend auch was von, wenn die Wallbox voll steuerbar wird dadurch
Keine Ahnung ob IPSymcon nun prüft, ob ein Parent vom Typ 79827379-F36E-4ADA-8A95-5F8D1DC92FA9 vorhanden ist, den das Modul aber eigentlich gar nicht braucht. Denn normalerweise arbeitet das Modul über die HTTP API und adressiert diese direkt. Wäre eine “schöne” inkompatible Änderung…
Vielleicht kann @paresy mir hier ja mal kurz helfen?
Nur bei MQTT nutze ich das “ReceiveData”. Versuch also mal einen MQTT Server als Gateway zu setzen. Ansonsten brauche ich keinen Parent. Für den MQTT Fall habe ich wohl mal den Parent gesetzt.
Ehrlicherweise weiß ich gar nicht, was diese UUID 79827379-F36E-4ADA-8A95-5F8D1DC92FA9 identifiziert. Habe ich wohl mal irgendwo kopiert. Denn konkret finden tue ich sie in der Doku nicht…
Ich bin selbst noch auf der 7.2, da ich bisher keinen Vorteil in Upgrades sehe (die neue Visu reizt mich z.B. überhaupt nicht).
Also wenn ich meine MQTT Instanz wähle ist der Fehler weg, habe Mqtt am goe aber gar nicht aktiv.
Passt aber erst mal.
Jetzt ist mir beim einbinden mit PV Überschuss aufgefallen das der Sollwert für A immer wieder auf den Wert der App zurück springt. Max Wert setzen geht.
Wenn ich die Modbus Vorlage nehme kann ich den Sollwert setzen und bekomme im Modul auch die Rückmeldung.
Nur im Modul springt es zurück. Habe V2 und das auch eingestellt.
Ich schreibe auf die Variable “aktuell verfügbarer Ladestrom"
Es gibt doch die Modul-Befehle. Welchen verwendest du?
Ein setzen der Variable via z.B. IPS_SetValue funktioniert nicht.
Und: Ich habe dich (Tobitobsen) mal in den Test für die v2.3 aufgenommen, mit der das Problem in der 9.0 nicht mehr bestehen sollte (das Modul sollte als Testversion v2.3 also auch ohne MQTT Server funktionieren).