Go-e Firmware 56.8 and API-v2 / Mqtt

[mmilin29]

After upgrading the charger to 56.8, mqtt communications has been stopped
Checked on 2 chargers
Is there any changes in this area ?

I had to downgrade to 56.1 to have mqtt datas back

[erxbout]

There should not be such a change but I can reproduce the issue
I will have a look!

[erxbout]

Ok seems like I only could reproduce it once.. Weird..
Could you try again and provide the serial number if it does not work (since you downgraded there should be a button where it says "Switch to 56.8" that should be faster than installing the version again)

[mmilin29]

Upgraded to 56.8 and again no mqtt datas Charger is 246728

[erxbout]

With the new firmware the mqtt shows this error "error_type=TCP_TRANSPORT connect_return_code=ACCEPTED"
With the old it just works..

Do you have some logs on the broker side regarding the issue?
Is there a connection attempt or not even an attempt registered at the broker?

[mmilin29]

I understood the problem
we configured a mqtt user who has rights only on "go-eCharger." topics but since the latest firmware 56.8 he also tries to write in "homeassistant." topics
He is denied access to these topics and he stops there
However in the go-e app the "mqtt home assistant" flag is not activated
For me there is an issue on this point

[erxbout]

Thank you for this information!

Now I can reproduce everything needed and a fix should be available in the next firmware release

[thannerfabian]

Hi, is the issue fixed in 56.9 beta?

[erxbout]

It should be..

Important bit, is that the homeassistant topics are sent after successful connection if enabled in config

If there is still a problem let me know

[thannerfabian]

Do you know, if the version is stable? And can I switch back to non beta version, after I installed a beta version?

[erxbout]

Its still in testing but should be fine

You can always go back to the version you had installed before

[thannerfabian]

Thanks! I will check it and give some feedback.

[erxbout]

@thannerfabian any feedback?

[SoftwareBaumeister]

Its still in testing but should be fine

You can always go back to the version you had installed before

Ist it? I have a new go-e Gemini flex. Yesterday I tried to run Mqtt first time and got the same error. But I got the error also on 56.1 and 56.9. Maybe I make some mistakes on my side?!? Mqtt is 'active' in the app, but it is 'not connected'.

Writing with HttpApiv2 is working. I use a mosquito-broker and node-red.

Any idea?

[thannerfabian]

@erxbout sorry for the late reply. Yes I tested it and I had the same result as @SoftwareBaumeister, it sadly didn´t work. I validated the MQTT-Connection string again and the settings were correct.

[SoftwareBaumeister]

@erxbout

Here is the log of the mosquitto-broker:

1728332354: New connection from 192.168.178.41:49842 on port 1883. 1728332354: New client connected from 192.168.178.41:49842 as go-echarger_261397 (p2, c1, k120, u'gebhardt'). 1728332354: No will message specified. 1728332354: Sending CONNACK to go-echarger_261397 (0, 0) 1728332354: Received SUBSCRIBE from go-echarger_261397 1728332354: Invalid subscription string from 192.168.178.41, disconnecting. 1728332354: Client go-echarger_261397 disconnected due to malformed packet.

192.168.178.41 is the ip of ot the go-e. Any idea?

[erxbout]

Can you edit your mosquitto config that it also logs the loglevel debug?
add a line that says:

log_type debug

When I do that I see a subscribe like this:

If your config does not allow that subscribe then our connection will be terminated by the server and we can do nothing about that..

[SoftwareBaumeister]

Can you edit your mosquitto config that it also logs the loglevel debug? add a line that says:

log_type debug

When I do that I see a subscribe like this:

If your config does not allow that subscribe then our connection will be terminated by the server and we can do nothing about that..

I found my problem. I do the wrong config at the app. At mqtt-setting on field "prefix" the last sign was not the SLASH, e.g. "go-eCharger/12345/" is ok; "go-eCharger/12345" is not working.

Now it is working. For other newbies, at "URL" you need the following syntax: "mqtt://username:password@ip:port".

[SoftwareBaumeister]

@erxbout sorry for the late reply. Yes I tested it and I had the same result as @SoftwareBaumeister, it sadly didn´t work. I validated the MQTT-Connection string again and the settings were correct.

Maybe the same problem/solution, too? Best wishes...

[thannerfabian]

@SoftwareBaumeister should there relly be a whitespace before and after the password in the connection string?

[erxbout]

The whitespaces are copy paste errors i suppose
When saving this the app will display an error and the setting will not change

So to sum it up we have two separated issues here:

• Disconnect from mqtt due to a broker that does not allow to send certain topics (homeassistant.. should be fixed in betas)
• Disconnect from mqtt due to malformed SUBSCRIBE message containing the + wildcard (bug created, no firmware with fix available so far)
  -- Temp solution: make sure there is a trailing / in prefix topic
  -- Full solution would be something like automatically add a trailing / if not set by user...

[SoftwareBaumeister]

@SoftwareBaumeister should there relly be a whitespace before and after the password in the connection string?

No! My mistake. I updated my post

[powo01]

Still have the mqtt, any fireware after 56.2 don't working. My setup. go-e located in my guest network, my mosquitto broker located in another netwerk. Both networks are linked via a firewall rule. Up to 56.2 all working, any newer nothing. Duct to the to different network range no autoconfiguration will working, on the other hand just a port for mqtt connection should be enough

[LauGui2023]

I can confirm the same thing. Firmware 56.2 is correct, the following ones are not. I haven't tried a beta.

Also, when switching from one firmware version to another, I had to change the MQTT prefix from /go-eCharger/serial#/ to go-eCharger/serial#/ (note that I removed the / at the beginning) to avoid having an empty root topic on my broker. It could be a good idea to check the prefix validity before using it on MQTT.

I still love my go-e chargers :-)

[erxbout]

The whitespaces are copy paste errors i suppose When saving this the app will display an error and the setting will not change

So to sum it up we have two separated issues here:

* Disconnect from mqtt due to a broker that does not allow to send certain topics (homeassistant.. should be fixed in betas)

* Disconnect from mqtt due to malformed SUBSCRIBE message containing the + wildcard (bug created, no firmware with fix available so far)
  -- Temp solution: make sure there is a trailing / in prefix topic
  -- Full solution would be something like automatically add a trailing / if not set by user...

@powo01 have you tried to make sure there is a trailing '/' at the end of the mqtt topic?
Othervise I would need some logs if there is a different problem..

@LauGui2023 Would also need some logs there because we might have another problem if it is not working even when the topic prefix is checked for the trailing '/'

[powo01]

@erxbout of course I tried it with and without trailing '/'. By the way with the non working firmware version I m not seen any TCP traffic with wireshark at the node where mosquitto is running. Generic mqtt client error when mqtt is enabled. Any way to get more specific error log from the go-e ? At the moment I use http api as a fallback

[pitkaha]

Still have the mqtt, any fireware after 56.2 don't working. My setup. go-e located in my guest network, my mosquitto broker located in another netwerk. Both networks are linked via a firewall rule. Up to 56.2 all working, any newer nothing. Duct to the to different network range no autoconfiguration will working, on the other hand just a port for mqtt connection should be enough

Having the same problem when Go-e (FW57.1) is in different (IoT) VLAN, even though traffic rules allow traffic to HA in main VLAN, all other IoT-devices work as they should. Moving Go-e to main VLAN fixes this. Not a network engineer but the firewall rule should not be a problem, allowed all traffic from IoT to HAs IP and still nothing.

Any tips?

[erxbout]

@powo01 I can try to have a look with the serial number of the charger if the cloud is enabled. But not seeing anything on wireshark is very strange, there should be at least the connection attempt. Maybe there is a problem with a network device that got also an update and changed some restrictions in the firewall?

@pitkaha interesting, I could also try to look into this with the serial number but I assume if the charger is in a seperate vlan it will not be allowed to talk to our cloud..
Is the mqtt broker also on HA Ip or is it somewhere else? Or is the HA integration using http?

[pitkaha]

@pitkaha interesting, I could also try to look into this with the serial number but I assume if the charger is in a seperate vlan it will not be allowed to talk to our cloud.. Is the mqtt broker also on HA Ip or is it somewhere else? Or is the HA integration using http?

Okay, thanks, serial is 261558. It is allowed to talk to cloud in both VLANs, and the cloud is working with both VLANs. MQTT is running on same ip with HA, its a NUC running HAOS 2024.11 with mosquitto broker (6.5.0) addon, and HA is using MQTT.

[powo01]

@erxbout there is no configuration changing between the different firmwares. In the moment I go rollback to the 56.2 firmware it's working again otherwise no connection possible. Cloud connection and also HTTP api working at all firmware versions. But there must be a software change in the mqtt area in later firmwares than 56.2 otherwise this behavior would not possible. Looking like unencrypted mqtt port 1883 and not the own subnet not working anymore. The behavior is shown at IPv4 and also IPv6

[erxbout]

@pitkaha I tested with 56.1 and latest 57.1 it seems like there is no difference, the connection can not be established..
As its in the IoT network I guess its also in the IoT VLAN?
That is not easy to debug only from the charger but I can see that ICMP Pings are running into a timeout and that I can not make an HTTP request to the IP:8123 (homeassistant) that is specified in the MQTT Url
Also I noticed that the MQTT url contains default user credentials, is that on purpose?

@powo01 Ich kann ohne die Seriennummer nichts genaueres rausfinden und auch damit sind meine Möglichkeiten begrenzt, da ich die Netzwerktopologie unmöglich kennen kann..
Wenn es eine Änderung gibt bezüglich MQTT dann in der Library die wir dafür verwenden, allerdings müsste zumindest irgendein versuch der Verbindung mit wireshark auffindbar sein, ansonsten gehe ich davon aus, dass das Netzwerk die TCP-Pakete nicht weiterleitet.

[pitkaha]

@pitkaha I tested with 56.1 and latest 57.1 it seems like there is no difference, the connection can not be established.. As its in the IoT network I guess its also in the IoT VLAN? That is not easy to debug only from the charger but I can see that ICMP Pings are running into a timeout and that I can not make an HTTP request to the IP:8123 (homeassistant) that is specified in the MQTT Url Also I noticed that the MQTT url contains default user credentials, is that on purpose?

Yep, different VLAN. Found the reason, there was one old and quite restrictive firewall rule I had overlooked, have to replace it with better one. MQTT is going through now. And yes good point, have to update those credentials, thank you for your help!

[powo01]

@erxbout mein go-e hat die Seriennummer 221479. Ich werde bei mir mit Wireshark nochmal in dem Netzwerk Segment schauen wo der go-e drin ist und den go-e auch mal in das Segment legen wo auch der mqtt broker drin ist. Hat sich die Versionsnummer Ihrer mqtt Library geändert ?

[powo01]

@erxbout Screenshot det APP

[powo01]

@erxbout die mqtt Probleme und Fehlerkdung bleiben auch bestehen wenn sich der go-e und der Mosqitto Server sich im gleichen Subnetz befinden

[erxbout]

@powo01 Ist die domain richtig gesetzt? Beim Auflösen am charger versucht dieser mit 0.0.0.0 zu verbinden und wenn ich die domain auflösen möchte ist der A record leer..

Könnte das das Problem sein? Wie sieht es aus wenn die mqtt url direkt die IP drin hat?

[powo01]

@erxbout der Host hat eine IPv6 only Adresse und damit nur einen AAAA. Ich habe es natürlich auch mit der internen IPv4 des Brockers direkt versucht. Laut Fehlermeldung hat der Mqtt Client bei der Initialisierung ein Problem. Und mit der alten Firmware 56.2 hat genau dieses Setting ohne Probleme funktioniert. Wenn ich ein Rollback auf die 56.2 mache geht es wieder, nur der Android Client nervt dann mit den Firmware Updates. Der go-e ist in meinem Gastnetz und der Mosquitto Server in meinem Core Netz. Vom Gastnetz ist der MQTT Server über eine Firewall Regel erreichbar, wenigstens bis Firmware 56.2. Bei jeder neueren Firmware sehe ich mit Wireshark am Gastnetz Eingang des Routers keinerlei MQTT Traffic auf Port 1883. Angehängte Screenshots sind nach dem Rollback auf die 56.2