Back from summer things and time to continue here. @peltsi51, could you shere a sample of the flow where you use the condition “charging”, so that I can setup a test scenario here.
Here is one flow where I use it. Nevertheless the condition card didn’t work in any simpler flow either.
I had the problem multiple times during the summer, but lately (about two weeks) I haven’t noticed it anymore. Don’t know what could be changed or is it a coincident.
Like I said before the http status page of the charger did show the correct state and also the homey go-e charger device showed the correct state, but the condition card didn’t.
Might be hard to debug, but good luck.
Wow, quite complex 
I have a test flow now running logging everything to a google sheet.
Hopefully I will be able to find the issue.
From the past what I have experienced with the builtin Date & Time trigger cards, that in some unknown conditions they might not trigger. This was on a HP2019, now however my primary is HP2023 so there may be a difference there also.
1 Like
So far all of the tests are working as expected and have not had a state difference between the device and the app. So for now, I can not reproduce @peltsi51 your problem. Let’s keep an eye on this.
It may just be that some of the scheduled queries every 5 or 10 seconds fail. Could you add to your flow a notification to the condition card (the red line) to catch that error and log it for you.
Then again your debug report did not show such issues.
Authentication and Allow Charging
While investigating @peltsi51 issue, I stumbled on an other issue related to how authentication in V3 and V4 related API works.
If you are using authentication either by the mobile app (anonymous auth) or RFIDs and you have security settings set to wait for authentication, non of the allow charging actions will work until someone authenticates.
I’m working on a new feature to support authentication When authentication is required, allow_charging will not change state · Issue #17 · oh2th/com.go-e.charger · GitHub
However, if you need allow charging to work, there are two ways:
- make sure you authenticate, when you plug in your car, so that your flows will work.
- or disable the security feature in the device settings in the mobile app, anyone who plugs in can charge.
I’m surprised that no one has reported this yet.
Question to go-eCharger V3 and V4 users.
- Should the Homey go-eCharger app automatically authenticate the anonymous user when
Allow Chargingis set to true either by a flow or from the UI?
Or
- Would it be better to add a new flow card to authenticate the anonymous user (and later a specific RFID tag user). This could be a UI action also as a list type picker.
The latter is a little bit more work, however it would bring the RFID tag support slightly closed.
I can imagine that the majority of Go-e Charger users are private users who make purely private use of the charging stations, and therefore don’t use the authentication functions. That’s probably why no problems have been reported to date. Personally, I don’t use the authentication functions, and I must confess that I didn’t fully understand your question. I’m only speaking for myself here of course, but I’m interested that whatever changes are made, everything continues to work as before for users who don’t use the authentication function 
1 Like
The condition card works properly (no error message), but it gives that the the car is not charging, although the car is actually charging and the Homey device also shows charging.
It’s now again happening. Do you want me to check something? Here are some pictures and the status page of the charger.
{"version":"B","tme":"1309230715","rbc":"126","rbt":"1742132960","car":"2","amp":"6","err":"0","ast":"0","alw":"1","stp":"0","cbl":"20","pha":"63","tmp":"28","dws":"3835802","dwo":"0","adi":"0","uby":"0","eto":"91832","wst":"3","txi":"0","nrg":[217,217,219,1,60,60,59,13,13,13,0,397,100,100,100,13],"fwv":"041.0","sse":"007232","wss":"********","wke":"************","wen":"1","cdi":"0","tof":"0","tds":"1","lbr":"153","aho":"0","afi":"0","azo":"0","ama":"16","al1":"6","al2":"7","al3":"8","al4":"10","al5":"16","cid":"255","cch":"65535","cfi":"15132337","lse":"1","ust":"0","wak":"f1e974a8f8","r1x":"2","dto":"0","nmo":"0","sch":"AAAAAAAAAAAAAAAA","sdp":"0","eca":"0","ecr":"0","ecd":"0","ec4":"0","ec5":"0","ec6":"0","ec7":"0","ec8":"0","ec9":"0","ec1":"0","rca":"","rcr":"","rcd":"","rc4":"","rc5":"","rc6":"","rc7":"","rc8":"","rc9":"","rc1":"","rna":"","rnm":"","rne":"","rn4":"","rn5":"","rn6":"","rn7":"","rn8":"","rn9":"","rn1":"","loe":0,"lot":25,"lom":0,"lop":1,"log":"CSCBWLRI","lon":0,"lof":6,"loa":0,"lch":0,"mce":0,"mcs":"test.mosquitto.org","mcp":1883,"mcu":"","mck":"","mcc":0}
You could have a look at Homey Developer Tools when this happens. There is capability is_charging that should of course be true when charging. That is the capability the condition card is looking when it is needed.
In addition you could use Trigger Charging changed to monitor and log the changes for that capability.
Capabilities
| ID | Title | Type | Value | Set Value | Last Changed |
|---|---|---|---|---|---|
| transaction | User Card | enum | auth_none | ||
| authentication | Wait for Authentication | boolean | true | ||
| alarm_device | Device Error | boolean | false | ||
| is_connected | Car connected | boolean | false | ||
| is_charging | Car charging | boolean | false | ||
| is_allowed | Charging Allowed | boolean | false | SET | |
| num_phases | Charging phases | enum | 3 | SET | |
| button_three_phase | Three Phase Charging | boolean | true | SET | |
| button_single_phase | Single Phase Charging | boolean | false | SET | |
| status | Device Status | enum | station_idle | ||
| current_max | Maximum Current | number | 16 | ||
| current_limit | Current Limit | number | 16 | ||
| cable_limit | Type-2 Cable Ampere | number | 20 | ||
| measure_temperature.charge_port | Port Temperature | number | 25.5 | 46 seconds ago | |
| measure_temperature | Temperature | number | 20.5 | 1 second ago | |
| measure_voltage | Voltage | number | 694.71 | 1 second ago | |
| measure_current | Current | number | 0 | ||
| measure_power | Power | number | 0 | ||
| meter_power.session | Energy Last Session | number | 34.61 | ||
| meter_power | Energy | number | 2125.28 |
Basicly is_charging is derived from the status of the go-echarger with:
if (deviceInfo.status !== oldStatus) {
// API car = 1
if (deviceInfo.status === 'station_idle') {
await this.setValue('is_connected', false);
await this.setValue('is_charging', false);
}
// API car = 2
if (deviceInfo.status === 'car_charging') {
await this.setValue('is_connected', true);
await this.setValue('is_charging', true);
}
// API car = 3
if (deviceInfo.status === 'station_waiting') {
await this.setValue('is_connected', true);
await this.setValue('is_charging', false);
}
// API car = 4
if (deviceInfo.status === 'car_finished') {
await this.setValue('is_connected', true);
await this.setValue('is_charging', false);
}
}
You can use this to filter down to the values I use from the api, to limit the amount queried.
http://IPADDRESS/api/status?filter=sse,fna,car,alw,acs,frc,trx,err,wh,pha,nrg,eto,tma,amp,ama,cbl,fsp
At this time I can not see why it shouldn’t be correct.
1 Like
The is_charging in the developer tools gives true as it should. The status in developer tools is showing car_charging. But the condition card gives false 
Hmm. Something strange happening, but cannot catch how and why.
1 Like
If you replace the condition card with a logic card for yes/no condition and use the Charging tag from go-eCharger?
They are directly interchangeable and practically does the same comparison.
1 Like
More debugging:
- Device shows charging
- Goe app Condition card charging is false
- Condition card yes/no with charging tag is giving no
- Device status tag contains car_charging, seen in comparator condition card and in development page.
- Charging tag contains no, seen in development page
I will change the used condition cards to condition card with device status tag containing word “charging”
1 Like
This is so strange as I can’t seem to replicate the issue.
Strange it is.
I cannot also say that why this happens or in what cases, seems quite random because it doesn’t happen always.
Nonetheless I got workaround to the problem, so until the mystery unveils itself I’m happy with the workaround.
Thanks for the help!
Could it be somehow possible that this part of the code for some reason doesn’t get excecuted? For example the oldStatus doesn’t get set in “previous round”. Would this lead into the case that the device status tag is correct but the conditions are wrong? Just guessing here.
Well, not ruling that out, so will need to look in to that. Then again that one should make the problem visible to more people.
1 Like
There is a really small chance that device status could be out of sync if the and cards are used in a flow that is triggered every 5 seconds, which is the internal interval of the app to update information from the charger.
It just might be that if the flow is running exactly at the same time when the update interval happens, the flow might get different values.
I’ll change the code order so that it should run the status dependant capability updates together.
Probably need to add some checks on the condition cards, to wait for the capability update to completem before returning a result.
New update (test: 2.6.1)
Changes include
- Group status related capability updates together. Could help in status being out of sync when a flow is running.
Note: The internal interval for the device updates is set to 5 seconds. I do not recommend to have flows that triggers also every 5 seconds, better to trigger a bit less often.
@peltsi51 , could you try the test version if that would help with the condition cards to be in sync with status.
1 Like
Up to this point the condition card worked with the test version, but for some reason now it doesn’t. But the device status tag is working correctly.
Feels like this problem is only with my setup so don’t feel obliged to debug this any further.
1 Like
New update (live: 2.6.3)
Changes include
- FIX: Change how active phases are counted for charging amps.
New update (test: 2.7.0)
Changes include
- FIX: 1-phase (~235V) vs 3-phase (~400V) voltage calculation.
voltage miscalculation · Issue #27 · oh2th/com.go-e.charger · GitHub
