I think it is important to point out that it is not so much the new hardware that requires a new app, it is the end of support for SKD-2 apps. (or the need to upgrade to SDK-3 at some point)
I would really like to do the work, but there is so much involved. I’m not a total expert on this so that also makes it hard to make promises. I really need the beginners guide to homey-app-building and I haven’t found that yet.
Things to look into with the new app apart from SDK-3:
Discovery has to be improved. But I haven’t found the right discovery strategy for the Go-e charger
New hardware (V3) with new software for the Go-e Charger (there is a new hardware version for the Go-e charger (with new options in the software like switch between 3 and 1 phases), and there is a new Go-e charger (Gemini)) - I don’t own either of these so it is impossible for me tot test.
HTTPS support, right now ‘my’ homey app only supports http. I should also support HTTPS and perhaps some form of password protection so your go-e charger doesn’t have to be on your wifi network unprotected. Another way to go about this is to hook onto the cloud of Go-e. But that has it’s own disadvantages like a limit on status updates and the requirement of an internet connection to be available (so less reliable)
Issues to be resolved, some small (like the calculation issue) some big (like the multiple device issue)
And athom was charging money for developers to make the apps available on the previous new homey (the cloud version). I’m still not sure if that goes for the new Pro too. That would be a deal-breaker at this time for me…
As regards to the new Pro, I haven’t ordered mine, as for my home I don’t really need the hardware at this time. And the price quite steep.
Finally, my wife says I need a hobby outside of the house, so I’m also not sure how that whole situation will play out.
So the conclusion is: I will probably find a way to keep the app working even under SDK-3, but i’m not sure when and unfortunately I cannot make any promises
@Tim_Willemsen Dear Tim, thank you very much for your answer. Although I would like with all my heart that the app for the Go-e Charger is supported by the new Homey Pro (Early 2023) - respectively that it is converted to be compatible with the SDK V3 - unfortunately I can’t do anything to help you (except to offer you a contribution to the costs you might have?!). I also understand your wife’s remark, because I have a wife who makes the same kind of remark to me as to you
However, and if it may be of any help to you: at the very recent “The new Homey Pro - Ask Me Anything”, it was stated that: “Converting from SDK V2 to SDK V3 is insanely easy, it’s easily just changing a few pieces of code” (approximately at the minute 16:00). Furthermore and at 42:35, they talk about a developer documentation guide and again indicate that a migration is really very simple to do.
Hi Tapio, although right now I’ve started anew with setting up the app for SDK3, I would definitively consider doing a transfer. Do you have any other apps on the app store?
Using v2 API would mean my own Go-e charger would no longer work, though as it only supports v1:
I would first do v1, since it is common for all devices. Idea was that the app could first try v2 and fallback to v1 if v2 does not give any response.
This way, one device in the driver could be enough and make it simple.
One thing I would be interested in, that does a V1 device advertise itself with mdns, like V2 does.
I.e. if you run “avahi-browse -r _http._tcp” on an linux machine fo yo get
= eth0 IPv4 123456 Web Site local
hostname = [go-echarger_123456.local]
address = [192.168.4.16]
port = [80]
txt = ["serial=123456" "friendly_name=123456" "manufacturer=go-e" "devicetype=go-eCharger_V4" "version=054.7" "protocol=2"]
Mainly interested on the protocol value, if that already tells the api version.
Idea is that Homey could do a discovery for the devices in the lan. This would allow to use dynamic addressing on the go-eCharger.
Don’t have any other apps yet on the store. Or we could split for now, and I will concentrate on the V2 and you keep V1.
I would first do v1, since it is common for all devices. Idea was that the app could first try v2 and fallback to v1 if v2 does not give any response.
That’s a great idea. If you’re able to demonstrate a working SDK3 test version of the app I will happily transfer the app to you. And would also be available for testing and support. Let’s see where we get.
I.e. if you run “avahi-browse -r _http._tcp” on an linux machine
I will try this soon. Right now I don’t have a Linux machine hanging around so i’d have to setup one. There’s no Windows alternative, right?
In my dev version of the app, I have succesfully setup mac address discovery. That could be an alternative maybe? Especially if it is possible to check v1 and v2 API availability afterwards?
I was also thinking for MAC address, however those may change over time. If V1 go-e Chargers support mDNS, I think that would be the way to go. I have a working discovery for the Gemini series now.
I’ve tried many types of ‘bonjour’ browsers, for instance for my Android phone.
I can discover many devices but not the Go-E charger Home+.
So I’m afraid this won’t work for the V1…
That is a shame. Then we would need to allow manual IP configuration or maybe use MAC discovery.
So a question for current Homeplus owners, what is your devices manufacturer part of the MAC address? I.e. The first three values AA:BB:CC:00:00:00?
Would your’s fit in the range of 98:FC:84:10:00:00 - 98:FC:84:1F:FF:FF as I found in one MAC database?
Current dev version in git doesn’t have manual config for IP address, was assuming that Home+ would alao advertise itself.
Let’s try to add MAC address discovery first.
Noticed that flow cards are on app level, instead of driver/device level, this prevents multiple chargers from working properly. Moved the flow cards in the new code to be driver specific, to allow multiple instances of a driver.
