I read through the thread on the user-contributed code for providing NTP service-based time updates and remote setting of clock parameters via the WIFI module. This was working for me with an older version(version 48) of the v1 clocks. The code was to be integrated into the v1 official source code.
However, the v1 code is now at version 56 and the included WIFI module code still does not have NTP support., although the latest v2 code does. However the v2 code with NTP support appears to work only for version 54 and is untested even for that.
Was this effort abandoned for v1 hardware?
I am unable to get even the latest v1 wifi module code to compile for a NodeMCU ESP-12E module, although an older version works just fine.
Figuring out what code works with which hardware has been a bit of a nightmare with the multiple repositories, support boards and web sites. I think I have it figured out now, but there does not seem to be a working NTP solution for the latest v1 code.
Hi Don, I'm going to have to look into it. I'm pretty sure I back-ported everything, but am not sure if it simply didn't make it into a release, or if I have it on a computer somewhere and need to push it.
The plan is of course to have feature parity if that's attainable. Some things can't be done (PIR on V1 for example) but otherwise, the idea is to have the same code for everything.
The I2C protocal is different between V1 and V2: There are extra options that need to be managed for things like the PIR. I'll make an update for it, or find the one I already did. It's supposed to work as you are expecting, but clearly something went wrong on the way.
I end up juggling too many versions and designs, and things get left on the desk, and then forgotten.
Ian, the code has some conditionals based on the I2C comms version. What I provided supports v54 and v62. Anything else it will report as "unknown," and won't work. I don't know what v56 is comparable to, or if it's different than either.
Anyway, search for "v1v54" and/or "v2v62" to see what the code is doing.
I'm probably going to rework the I2C protocol. It sort of developed organically and has outgrown its original scope. Getting the current config as a "block" all in one go new feels like a dead end - it caused me to add the "protocol field" to try to keep track of the contents of the block and now managing multiple versions is getting onerous.
I'm likely to get individual elements from the clock on demand, so that any clock can respond to the fields it knows about, and respond "I don't know" to the ones it does not know about. This is likely to allow me to manage the code base better and let the user know when something is wrong. On the other hand, it would also be a good idea to just tell the user in the GUI if there is a protocol version failure.