Feature idea: multicast real time power consumption data?

Support
1

I’ve been thinking about building a custom off-grid solar diversion load controller for controlling a hot water pre-heater tank and a tankless supplemental water heater.

The goal is to only power the pre-heater from solar while still ending the day with a full battery. I really want to avoid discharging the battery to pre-heat water. I’m willing to use the battery to heat time-of-use water with the tankless heater, but I’m hoping that the system will be sized so that this is a rare event.

I don’t have a direct way to estimate how much “excess” solar is available. Both the inverters and batteries are going to be AC coupled. I will have to sneak up on the amount of excess by tracking the output of the solar inverters, the consumption of the house and the battery charge/discharge rates. I can then adjust the PWM frequency of the two pre-heater elements to regulate how much power is used heating water.

For this to work I would need lowish latency real time power consumption measurements. Rather then including current transformers in my design, I was planning on getting the data from an iotawatt.

So, I was wondering what is the lowest compute cost way to get continuous real time current consumption data out of the iotawatt, without relying on another piece of equipment to proxy the data. I only care about the most recent live measurements with as little latency as practical over wifi.

Instead of doing a constant stream of http requests, I was thinking it might be useful for the iotawatt to just periodically send the power measurements via UDP multicast. A single 1500 byte UDP packet should be able to contain the all the real time power measurements, even if encoded verbosely as json. One packet, a few times a second would provide enough data for my diversion controller to roughly track the generation/consumption/charge/discharge rates and adjust the duty cycle of the pre-heater so the battery doesn’t discharge.

For the iotawatt, you can’t get any lower cost then UDP and you don’t have to do anything special to transmit multicast data (that is handled by the network and the receiving side). Using UDP, I don’t have to worry about stale data and it would be fairly tolerant to packet loss, because only the most recent measurement matters.

Another option would be SNMP, but just sending simple text messages over multicast is much less work for the iotawatt and my controller.

Would anyone else find this feature useful?

1 Like
2

I don’t see why a client cannot make HTTP API calls effectively, but it would be trivial to include a UDP broadcast with GitHub - me-no-dev/ESPAsyncUDP: Async UDP library for ESP8266

3

I was actually concerned about the load on the iotawatt and not the load on the client side making the requests. Making the request is cheap, servicing it isn’t. Having the iotawatt multicast out the power consumption data would put a much lower burden on the iotawatt then multiple diversion load devices polling the HTTP API. It would also result in much better behavior if the iotawatt in transient overbudget conditions (not sending a multicast packet vs having to deal with new TCP connections that it can’t afford to service).

The other advantage of a broadcast model is that the resulting data would have much lower latency and more deterministic jitter. I suspect with the data I have available I won’t be able to tightly track the available solar power without causing the AC coupled battery to make up the difference. But how well it works will depend directly on the quality and timeliness of the data from the iotawatt.

4

If i was doing this - i would look at the code and see if it is possible to get MQTT going in the IOTAWatt - it is designed for constrained devices.

You can then put a RPi as your MQTT broker and use whatever your programming language is (i would use Node Red) on the RPi and control your diversion loads this way.

Depending on your internet access levels - the Rpi could also source external weather data to be able to make educated assumptions about likely solar generation based on proposed weather patterns etc

Craig

5

Just throwing in my support for an MQTT option. I’m looking for a (near) real-time trigger option that would allow me to act quickly upon a power usage event.