UPDATE 31.10.: Amazon Alexa - ioBroker Skill läuft aus ?

[Wildbill]

@homoran Was lange währt... :blush:
Ja, so Dinge kenne ich. Habe mir auch schon bei einigen Dingen selber ein zwei Beine gestellt oder das Leben unnötig schwer gemacht, weil ich an anderer Stelle Perfektionist bin und die Firewall penibelst eingestellt habe, so dass nichtmal eine digitale Fliege durchkommt. Aber Ende gut alles gut. Ich denke, mit der Box macht man keinen Fehler.
Ich meine auch, irgendwo geelsen zu haben, dass zumindest der WLAN-Key und die SSID die Box nicht verlassen und lokal gespeichert werden. Ob es so ist, müsste mal jemand mit Wireshark nachforschen. In der APP könnte es ja auch nur lokal gespeichert sein und deshalb auch bei Cloudzugriff sichtbar. Sehe ich aber weniger ein Problem, meine SSIDs sind alle sichtbar, ohne Passwort fängt damit auch niemand was an. Und SSID unsichtbar ist auch keine Sicherheit. Mit Linux- oder Android-Tools werden die unsichtbaren dann genauso schnell angezeigt. Die über Funk übertragenen Daten lassen sich nicht verstecken.
Der Hotspot-key ist der Box und damit dem Hersteller ja eh bekannt, wenn das in die Cloud gehen sollte, dann landet es ja da, wo es herkommt und eh schon bekannt ist.

Das heisst, Du hast der Box nun komplett Internet entzogen, also auch keinen Cloudzugriff mehr (nach dem Update), aber alle Dinge wie API und MQTT spielen anstandslos weiter?! Gut zu wissen.

Gruss, Jürgen

[Homoran]

@wildbill sagte in Go e-charger:

Du hast der Box nun komplett Internet entzogen, also auch keinen Cloudzugriff mehr (nach dem Update

Hatte ich vor, aber träge wie ich bin, noch nicht umgesetzt, weil...
Die Box ist nur über das WLAN erreichbar, indem die App über die Cloud geht :rage:

Und nur dann hat man alle Optionen

Also APP auf den Handy im WLAN -> cloud -> WLAN -> Box
ein direkter Zugriff mit der App aus dem WLAN an die Box geht nur über den AP in der Box, und da sind die Infos arg limitiert

[Wildbill]

@homoran Wie meinst Du das, nur über WLAN erreichbar, indem die App über die Cloud geht?
Klar, ohne Internet ist die APP mehr oder weniger nutzlos bzw. lässt sich nur im Hotspot-Modus verbinden. Aber der Zugriff per API oder MQTT hat doch mit der App nix zu tun.
Und einmal die Box via APP ins eigene WLAN gebracht und HTTP-API und/oder MQTT aktiviert oder eingerichtet braucht man die App doch eigentlich nicht mehr. Lässt sich doch dann alles viel komfortabler über iobroker steuern.

Gruss, Jürgen

[Homoran]

@wildbill sagte in Go e-charger:

Wie meinst Du das, nur über WLAN erreichbar, indem die App über die Cloud geht?

so:

API ist klar (noch nicht ohne I-Net getestet) aber die direkte Bedienung über die App geht sonst nicht
und in ioBroker hab ich noch nicht alles drin

[Wildbill]

@homoran
Ja, also wie ich geschrieben hatte.
Brauchst Du die App zwingend in Zukunft? Zum steuern wäre ja auch VPN-Zugriff von unterwegs auf iobroker möglich. Oder per Telegramm, wenn es nur so Dinge wie Laden ein- und ausschalten und mal die Leistung manuell anpassen sind. Und normalerweise bin ich zumindest daheim, wenn das Auto lädt...
Vielleicht schreibst Du ja, wozu Du die App weiterhin verändern willst, da hast sicher jemand eine passende Idee.

Gruß, Jürgen

EDIT: Hattest wohl noch editiert. Ja, solange nicht alles in iobroker ist, ist es klar.

[Homoran]

@wildbill sagte in Go e-charger:

Brauchst Du die App zwingend in Zukunft?

Das wird sich zeigen.

@wildbill sagte in Go e-charger:

Zum steuern wäre ja auch VPN-Zugriff von unterwegs auf iobroker möglich

Das brauche ich jedenfalls nicht!

Wäre schön, wenn dei App auch für lokale Steuerung freigegeben wäre und nur bei Bedarf (Updates o.ä.) ins I-Net müsste

[Wildbill]

@homoran Kannst ja bei Go-e mal anfragen oder direkt bei denen bei Github ein Issue aufmachen. Soweit ich sehe, sind die da teilweise recht angetan, was Ideen von User angeht. Vielleicht tut sich da ja was.

Gruss, Jürgen

[Homoran]

Habe heute wieder extreme Mühen gehabt, nachdem ich den Charger wieder in der Garage angeschlossen hatte ihn ins Netz zu bekommen.

Ich habe verdammt viel rumgespielt, aber kein System erkannt warum es nicht ging :rage:

Jetzt ist er wieder im Netz. Aber seitdem bekomme ich eine WARN im log. nicht gerade aussagekräftig:
go-e.0 2021-02-20 11:50:38.833 warn (22708) Error in go.e: {}

habe dann das debug aktiviert, der erste Ausschnitt sieht dann so aus:

2021-02-20 11:41:38.796 - debug: go-e.0 (22708) Starte Abfrage an: http://192.168.xx.yy/status
2021-02-20 11:41:38.827 - debug: go-e.0 (22708) Response: 200 - OK
2021-02-20 11:41:38.827 - debug: go-e.0 (22708) {"version":"B","tme":"0101-300139","rbc":"26","rbt":"2366449","car":"1","amp":"6","err":"0","ast":"0","alw":"1","stp":"0","

Da kommt dann das gesamte JSON, aber der Fehler könnte bereits
2021-02-20 11:41:38.827 - debug: go-e.0 (22708) {"version":"B","tme":"0101-

dieser sein.

Ich frage mich nur, warum das gestern im Testbetrieb nicht passierte, sondern erst, nachdem er vom Netz getrennt war???

[Wildbill]

@homoran Kommt tme als Wert auch so, wenn Du http://192.168.xx.yy/status im Browser aufrufst?
Bei mir kommt bei tme das hier:

tme	"2002211201"

Also ohne Bindestrich "-"
Im iobroker habe ich dann sauber Datum und Uhrzeit im Datenpunkt:

Fri Feb 21 2020 12:02:00 GMT+0100 (Mitteleuropäische Normalzeit)

Vielleicht hilft es ja, den go-e nochmal stromlos zu machen und neu zu starten.
Hast Du ihn bereits vom Internet getrennt? Könnte auch sein, dass er keinen NTP-Server mehr findet und deshalb keine Uhrzeit mehr setzen kann. Keine Ahnung, wo er sich die Zeit holt.

Gruss, Jürgen

EDIT: Anscheinend ist es europe.pool.ntp.org wenn man verschiedenen Foren und Seiten glauben mag.
EDIT2: Ja, der ist es. Hier hat sich mein go-e gerade die Zeit geholt. Ausschnitt ist aus Pi-Hole:

2021-02-20 12:05:05	A	europe.pool.ntp.org	go-echarger	OK (forwarded to localhost#5335)	IP (0.3ms)	

[Homoran]

@wildbill sagte in Go e-charger:

Bei mir kommt bei tme das hier:

so steht es auch im code:

// TME provides 2208201643
            // Realdate: 22th August 2020 at 16:43 (CET)

Bei mir kommt:
tme":"0101-300139

wobei die 101 ja im time-offset steht

[Wildbill]

@homoran Der offset 101 sollte aber im Parameter tof mitkommen:

tof	uint8_t	time_offset: Zeitzone in Stunden für interne batteriegestützte Uhr +100
Beispiel: 101 entspricht GMT + 1

tme sollte ein String dieser Art sein, ohne Offset:

tme	String	Aktuelle Uhrzeit, formatiert als ddmmyyhhmm
0104191236 entspricht to 01.04.2019 12:36

So steht es bei go-e bei der API-Beschreibung.
Für mich scheint es, als hätte Dein go-e einfach keine aktuelle Uhrzeit. Hast Du geschaut, ob er den NTP-Server europe.pool.ntp.org erreichen kann?

Gruss, Jürgen

[Homoran]

So, habe jetzt etwas mehr Zeit - Hoffentlich ;-)

@wildbill sagte in Go e-charger:

Hast Du ihn bereits vom Internet getrennt?

Ja, bereits gestern abend

@wildbill sagte in Go e-charger:

Kommt tme als Wert auch so, wenn Du http://192.168.xx.yy/status im Browser aufrufst?

Ja, kommt auch so

Im Code steht etwas von Version == C da habe ich noch B

@wildbill sagte in Go e-charger:

Der offset 101 sollte aber im Parameter tof mitkommen:

OK, da steht es auch drin

@wildbill sagte in Go e-charger:

ob er den NTP-Server europe.pool.ntp.org erreichen kann?

Kann er definitiv nicht, weil vom I-Net getrennt

EDIT:
Kurz ins Netz gelassen, jetzt is das Datum korrekt ;-)

Weißt du, wie oft er die Zeit abfragt?

[Wildbill]

@homoran Dann hast Du da wohl Deine Antwort. Anstatt der aktuellen Uhrzeit kommt bei tme dann bei Dir der obige Wert mit Bindestrich. Der bringt den go-e-Adapter wohl aus dem Tritt.
Meiner Meinung hast Du wenige Möglichkeiten:

• Issue beim Adapter, dass sowas rausgefiltert wird und er ohne aktuelle Uhrzeit keine warns oder errors produziert.
• Dem go-e zumindest Zugriff auf den o.g. NTP-Server erlauben. Bei mir wäre es in der Firewall vom Edgerouter 4 kein Problem, Deinen Netzwerkaufbau kenne ich nicht
• Damit leben (könnte ich nicht, warns und errors im Log nerver)
• Internetzugang erst einmal erlauben bis die Uhrzeit da ist und dann sperren. Wobei ich nicht weiss, ob bei späteren Versuchen dann wieder das obige gesetzt wird, wenn er keinen NTP mehr erreicht

Es gab wohl schon die Bitte an go-e, den NTP-Server frei setzen zu lassen. Bislang ist da aber nix mit drin. Vielleicht kommt ja noch was.

Gruss, Jürgen
EDIT: Nein, Intervall zum Zeitholen weiss ich nicht, ich durchsforsche nachher mal die Logs, wie oft er das macht.

[Homoran]

@wildbill sagte in Go e-charger:

Damit leben

ist keine Option, da er dann anscheinend auch die anderen Werte nicht einliest.
Dann müsste zumindest im Adapter geändert werden, dass

@wildbill sagte in Go e-charger:

sowas rausgefiltert wird und er ohne aktuelle Uhrzeit keine warns oder errors produziert.

@wildbill sagte in Go e-charger:

Internetzugang erst einmal erlauben bis die Uhrzeit da ist und dann sperren.

Hab ich jetzt erst einmal gemacht, aber

@wildbill sagte in Go e-charger:

ob bei späteren Versuchen dann wieder das obige gesetzt wird,

weiß ich auch nicht, deswegen die Frage, ob du weisst, wie oft der NTP abgefragt wird

[Homoran]

@homoran sagte in Go e-charger:

@wildbill sagte in Go e-charger:

Damit leben

ist keine Option, da er dann anscheinend auch die anderen Werte nicht einliest.
Dann müsste zumindest im Adapter geändert werden, dass

@wildbill sagte in Go e-charger:

sowas rausgefiltert wird und er ohne aktuelle Uhrzeit keine warns oder errors produziert.

@wildbill sagte in Go e-charger:

Internetzugang erst einmal erlauben bis die Uhrzeit da ist und dann sperren.

Hab ich jetzt erst einmal gemacht, aber

@wildbill sagte in Go e-charger:

ob bei späteren Versuchen dann wieder das obige gesetzt wird,

weiß ich auch nicht, deswegen die Frage, ob du weisst, wie oft der NTP abgefragt wird

auch ein EDIT ;-) :
Mein Netzwerk ist eine Fritzbox, in der ich nur I-Net Sperren kann (ggf. noch eine Regel erstellen, muss ich mal suchen) und das WLAN mit Unifi

[Wildbill]

@homoran So, die Box schaut exakt alle 5 Minuten nach dem NTP-Server. Wenn das Netz bei Dir wieder gesperrt ist, müsstest Du da mittlerweile sehen können, was passiert, wenn er nicht erreichbar ist.

Fritzbox kann AFAIK nur komplett sperren, bin da aber zu lange draussen. In Unifi geht es nicht, bzw. ginge nur, wenn ein Unifi security gateway als Router im Betrieb wäre.

Soweit ich weiss, hast Du einige Raspi in Betrieb. Wenn Du noch einen rumliegen hast, der auf Arbeit wartet, kann ich Dir nur Pi-hole ans Herz legen. Bei mir laufen zwei in Proxmox als LXC, einer für das Smarthome und einer für Laptop, Rechner usw. Die meisten Smarthome-Geräte haben keinen Internetzugang (Routerfirewall sperrt auf IP-Basis), für die, die es haben müssen, kann ich damit schauen, was so angefragt wird und bei Bedarf sperren oder durchlassen. Könntest Du ja im Netzwerk für den go-e auch so machen. NTP durchlassen und die restlichen Anfragen (Cloud und so) sperren.

Gruss, Jürgen

[Wildbill]

Ich habe das Log mal noch komplett durchsucht, was der go-e sonst so macht. Es scheint, dass er wirklich nur alle 5min den NTP-Server erreichen will. Ich sehe seit gestern morgen exakt eine Anfrage nach
i8p7v0.messaging.internetofthings.ibmcloud.com

und das war gestern zu einer Zeit, als ich die App kurz offen hatte und das Auto am Kabel hing. Gerade habe ich die App auch mal aufgemacht, da gab es keine weitere DNS-Abfrage. Möglicherweise versucht die Box auch nur die Cloud zu erreichen, wenn geladen wird, sich also aktiv Werte ändern und bleibt sonst stumm.

Gruss, Jürgen

[dskrt]

@wildbill Ich habe meinen Go-E seit gestern vom Elektriker angeschlossen. Aufgefallen ist mir bis jetzt:

Die Zeit wird falsch interpretiert: Fri 21 Februar 2021 gibt es nicht!

Der Zähler der Gesamtstrommenge zählt nur von man via Rfid-Chip das Laden aktiviert, und er rundet auf ganze Kwh!

Aktiviert man das Laden ohne Chip wird nicht gezählt, kann das jemand bestätigen?

[Wildbill]

@dskrt Das mit dem Datum und Wochentag ist mir gar nicht aufgefallen. Komische Sache. Da ich den Time-Datenpunkt nicht weiter auswerte ist mir das aber eigentlich egal. Da aber vom go-echarger schon als Datum der 21. kommt obwohl wir erst den 20. haben passt ja da schon was nicht. Mal beobachten, wie es sich die nächsten Tage entwickelt. Kommt das bei Dir auch so, oder steht bei Dir der 20.?
Gesamtstrom werte ich direkt im iobroker aus. Ich habe ein Script, welches saldiert und eigene Datenpunkte. Bei Ladestart wird der aktuelle Zählerstand (eine eigene Variable unter Javascript.0) als Startwert genommen, bei Änderungen des Datenpunktes

go-e.0.loaded_energy_kwh

dieser Wert dazu addiert und bei Ladeende dann der alte Zählerstand plus die aktuelle Ladung als neuer Zählerstand gespeichert. Somit habe ich exakt die geladene Menge und auch, wieviel ich schon insgesamt mit dem go-e geladen habe. Der Datenpunkt dws bzw. davon abgeleitet der o.g. rechnet kWh mit zwei Nachkommastellen, das reicht.
RFID verwende ich momentan (noch) nicht, dazu kann ich nichts sagen. Aber ohne funktioniert alles wie gewollt. Auch die im go-e gespeicherte Gesamtmenge wird aktualisiert.

Gruss, Jürgen

EDIT: Ich habe wegen des falschen Wochentags mal ein Issue bei Github beim Adapter aufgemacht. Der Adapter scheint ja das an sich schon falsche Datum vom go-echarger schon falsch zu interpretieren, was den Wochentag angeht. Warum der go-echarger aber meint, heute wäre schon der 21. ist mir ein Rätsel. tds Offset steht auf 1 und tof (time offset) auf 101 UTC. Ist das schon korrekt so?

[dskrt]

@wildbill Was das Datum angeht glaube ich dass dass ein Problem der falschen Interpretation der amerikanischen Notation ist: 20212002 am Freitag hatte ich Thu Februar 19, 2021 also 20211902.

Bei Ladeende ist bei mir gleich die geladene Energie wieder auf 0. Startest und stopst du den Lader auch über Iobroker ? Ich wollte im Prinzip meine Ladestatistik mit Sourceanalytix weiterführen an dem Punkt wo ich mit dem mobilen Lader aufgehört hatte. Wie gesagt, mein Go-e ist erst seit gestern angeschlossen und ich bin noch am rumprobieren...