Glyn hadn’t told me that he sent out any units. That said, I am happy to hear that he has. I was hesitant because it’s a lot more straightforward dealing with someone with a production unit vs the a homebrew device. Not to diminish those efforts, but the approach to problems is easier.
Yes, that is the current version.
This is a tough issue. All data logging is accomplished by reading from the log and posting to the server. That architecture makes possible the wifi/internet failure recovery and uncouples the server posting from data collection. So whatever gets sent to a server must be in the log. As I’ve been trying to get this thing under control and released, I have avoided mission creep, to the point where expanding the log file record is a backward compatibility and conversion issue as much as a technical challenge going forward. Let me process this in the background for a few days.
That concerns phase shifting L1 voltage to L2 and L3. That’s basically what the eMon three phase sketch does, if you like that, you should love this. The gold standard of course is using three VTs which is also supported.
The update server is just loading the update onto a server and downloading the file. There is a php file that you can query to find out what version is current for a patrticular update class, but then IotraWatt just downloads the file as it would any other file. So the update server is just any webserver like apache.
The update blob itself is a different matter. I build that offline in an ESP8266 device that I call my “enigma”. OTA updating is a security nightmare. IotaWatt doesn’t have enough heap to reliably use TLS for secure internet downloads, and a method of authenticating an update is needed anyway. I do that by signing the update blob with a private key that is kept in the EEPROM of my offline enigma signer. The corresponding public key is hard coded into IotaWatt. The OTA update requires that the update blob signature verifies with this public key. Most users will take comfort in this arrangement and my intention to never share the private key with anyone or even expose it to the internet.
So the issue becomes whether I want to become a CA and administrate update certifications beyond what I have already put in place, and will I also need a revocation process as well, and just how far do I want to go in reinventing the wheel?
Before I think about any of that, I’d rather explore the needs of the user base and see if they can be met with mainstream changes in the official releases. It is open, and you can do a pull request.