search

gazoodle / geckolib

Library to interface with Gecko Alliance spa pack systems via in.touch2 module
GNU General Public License v3.0
62 stars 24 forks source link

Version not found #26

Closed mmillmor closed 2 years ago

mmillmor commented 2 years ago

I was having an issue with the code not finding the configuration for my spa (Cannot find XML configuration for inYT v65). I looked at the XML file at http://intouch.geckoal.com/gecko/prod/SpaPackStruct.xml and saw that for inYT the version number is v63. So I wondered what would happen if I just ignored the version, and I changed const.py to the following, to remove the version check

SPA_PACK_CONFIG_XPATH = "./ConfigStructures/ConfigStructure" SPA_PACK_LOG_XPATH = "./LogStructures/LogStructure"

It appears to work fine when I do that. So the question is, should the code be ignoring the version, at least for some Plateforms?

jimbodude commented 2 years ago

I'm seeing the same behavior with v64. 63 is the largest LibRev that I have in the XML coming back from the spa.

gazoodle commented 2 years ago

I don't think ignoring the version is a good idea.

The SpaPackStruct.xml documents the layout of the spa pack firmware writable memory. In there will be locations for obvious things like pump run state, but also contains things like 1-phase or 3-phase supply, breaker current setting and so on. Writing to those locations if you're using the wrong data would have unpredictable results.

I don't see Gecko changing pack version numbers unless they've had to recompile the firmware for some reason and that has resulted in the compiler laying out memory differently. Of course it's possible that the stuff we're interested in is in the same location and it's only new stuff that has been added ... and this looks to be the case from your evidence, but it might not have been and I would be careful because of that.

I've been in contact with Gecko for a year now - well, I say contact what I mean is I made a LinkedIn connection with the CTO and put a case to them for working with us, but it's slow progress as I assume he has much more important stuff on his plate that a bit of open source hobby code :-)

Anyway, having waited for some positive update and after thinking about it for a while I think I'll just add the latest XML to this repo and download from there until we have a coherent plan for how to get the latest going forward. Caveat: I might have to remove this if Gecko don't want it in a public repo, but given that it's already in the public domain by being part of their app and at the end of a URL I can't see any big reason why we can't do this. I don't think it contains any proprietary information, just the location of various useful memory locations in the spa firmware.

Comments anyone?

mmillmor commented 2 years ago

I have no reason to doubt anything you say, but do you know how Gecko get their app to work if not via the XML file at that URL? My spa can be controlled fine from the app, so do they have the XML file baked into the app at a later version, or are they using that same file and ignoring the version number? I appreciate that if they ignore it because they know they can, that is different from the open source code ignoring it on a hope that it is OK.

As for putting the file in the repo, the good thing is it is faster to install. The bad thing is that it is not up to date if they ever do make a change. Perhaps install instructions could say that people can check for a later version and overwrite if wanted? That covers all bases.

gazoodle commented 2 years ago

I don't think they do ignore the versions. There seem to be multiple places that the XML file is located. The previous URL as you noted, but also packed in to the Android APK distro, and also on another URL https://api-intouch2.geckoal.com/api/spapackstruct but we've not been able to successfully get it from there yet (BTH I've not given it much attention time)

The version available from http://intouch.geckoal.com/gecko/prod/SpaPackStruct.xml has a file version of 19, and does indeed only contain InYT layouts to lib version 63, but later versions have lib versions up to 81

For now, I'll add the data to the repo in some fashion and accept that it may get out-of-date but we can always update the repo when this occurs and go from there, probably better than what we have at present as it's quite a bit out of date at present.

gazoodle commented 2 years ago

As potentially misleading as the title on #12 is, this is a duplicate, so I’m closing this issue as most of the conversation is in the other thread.