Automation Response Time?

I am vaguely contemplating replacing my dedicated Arduino controller with some sort of HA system.

Seems pretty straight forward, but there is one timing critical part, and that is the geyser switch. If total inverter load exceeds 8kW, I need to 100% reliably switch off the geyser within 10 seconds.

Can anybody with some practical home assistant/home automation experience comment on the various products out there and how quickly they can respond to complex inputs?


So you can set your HA to do something on a sensor’s state change and the response will be very fast. Presumably depending on the CPU clock of the HA device, but I’m just speculating.

So the speed of the response should not be an issue. You are concerned with the rate at which the sensor’s value update. If you use Victron ModBus, I think that happens every 30 seconds (it looks like it, I didn’t time it). Perhaps MQTT is faster? Almost want to say that my pool pump’s switch report its status change almost immediately.

It would be quite nice if there’s a way to speed up the ModBus publishing or potentially a way to pull the data without the Venus putting it on the bus.

I use my HA to automatically update the inverter limit to the PV output as soon as the GX puts the new PV output on the ModBus (and a few other things to not make this go bad when the batteries are full and there’s no load in the house) and that is 100% reliable thus far, and I’m running it on a Pi4, which really isn’t supposed to be stable.

Well, the HA application will have to do a ModBus pull - the Deye inverter does not push anything.

So there are a lot of issues - how often can it issue ModBus requests? How often does it run triggers? How complex can the trigger logic be, etc.

I have been browsing the manuals for various applications, but they are all rather vague on this sort of thing. Almost looks like I will have to install them one at a time, and test until I find something that works…

My MQTT update to my NodeRed Dashboard from the GX is 5s. It switches a Sonoff almost immediately.

@ebendl, we need your input as well please.

To put things in context, I have a simple Arduino Pro Mini which talks to the Deye and the geyser. It implements a complex look up table based on time of day, state of charge, solar production and load power to determine a target geyser temperature (as well as the overriding logic to turn the geyser off if load gets too high).

It has been running flawlessly 24/7 since installed about 9 months ago.

BUT it needs a UI. I need to be able to turn off the geyser when I go away, or override temps if I have guests, etc.

One option is to replace the Pro Micro with a D1 and build a simple web UI for it. This is probably the easiest option.

The other option is to build WiFi gateways for everything and run a HA system.

The second option is far more work, but will give a lot more flexibility, and standardise things a bit more for long term maintenance.

What I meant is that the inverter would need to update the value on the ModBus address you want to use. That is unlikely to be in real time. My GX does so roughly every 30 seconds. So if that is standard for ModBus, you won’t be able to use it.

Edit: There seems to be a scan_interval optional input for the sensors you load on Home Assistant through ModBus. I’m going to see if I can change that to 5 seconds and then whether it updates quicker. (Which might happen this weekend)

In my experience, yes it is quite fast. But there are no guarantees. And I have had, in my previous house, cases where a sonoff would not switch for several seconds after tapping the button on the app. I’ve even had one or two cases where I would switch it back off and then on again, and only then did the lamp I was controlling react. Since I moved, the issue disappeared. Might have had something to do with radio interference, I will never know.

You’re correct – the scan interval should be used to switch it to lower than 30 seconds, which is the default. I can’t find the official documentation that it is 30s, but this basically says the scan_interval is 30s by default for most sensors.

So I doubt the 30s delay comes from the GX side, probably from the Home Assistant’s side.

Note you can’t go lower than 5 seconds – see the Modbus section under “Other breaking changes” in the latest release’s change log: 2021.6: A little bit of everything - Home Assistant (

That being said, I’m not sure I would trust HA for that high level of availability, especially if you’re running a bunch of other things too. I know some guys have 2 home assistant instances – one running critical parts with high performance and reliability, the other running “nice to haves”.

In @justinschoeman 's case, what about keeping your geyser switch on the Arduino (simplifying the functionality to basically become a Wifi switch but keep some safety logic), but adding some additional code to interface it with Home Assistant? That way you can keep the low latency response on the geyser, but also have all the nice things in Home Assistant (and easier expandability).

I’ve actually thought of doing something similar on my geyser – but in my case, the problem is that the Sonoff controlling the contactor tended to drop off the network at certain times, and thus ends up never receiving the “turn off” MQTT message and running waayy too long (I have it run at 15 min intervals when my batteries are fully charged to help boost the temperature). Then again, I switched to the CBI Astute and seems better now.

1 Like

That is a pity. Would have been nice to move to a more standardised system.

Sounds like I will go ahead with the D1 swap, and just publish everything to MQTT for further consumption.

I’m not saying it isn’t doable on HA, just that I think a system with multiple safeguards can’t hurt.

If you’re going D1, you might even be able to do it with ESPHome or Tasmota, which would be a “less-code” solution and will integrate with Home Assistant much more easily.

How do you currently read the inverter load in your Arduino controller?

At the moment both the geyser and inverter are connected over RS485 to the Arduino, talking ModBus.

Implementing all the required logic on ESPHome or Tasmota will be a nightmare. Much easier to just port my current code across and move the config from EEPROM to FS so it can be easily updated.

The modbus registers updates as soon as the data becomes available on dbus (which is the IPC bus used in Venus and most other Linux setups), which is as fast as the various bits of software publishes them, which is usually about once a second. So yes… definitely not GX side.

The modbus side is faster than the mqtt side (if you prefer to use that instead). There is some rate limiting going on in the mqtt interface to lower the amount of traffic for things that changes too often, so via the mqtt integration you’d be looking at something more like 2 seconds.

But I can also perhaps take this opportunity to point out that some improvements are coming to the mqtt side in the future, which may well make it the easier way to integrate.

Edit: Also, I believe @justinschoeman has a non-blue setup, so a lot of the GX talk probably doesn’t matter to him.

Oh, and if you want to try the latest version, it’s here (for now, until merged), probably going into venus 2.80 or something like that.

On that note, did something change on the Venus large image. I see the last image update was in April.

No idea. Not my department :wink:

Amazing! I’m so glad I realised that it is actually the default scan interval that is doing this rather than the GX trying to save on some CPU cycles. Now I can further fine tune my inverter limits!

If I may, why not leave the current set up as is? You can then add a D1 as an interface between HA and your Arduino? That way, the core operation will not be affected by HA being available or not, nor are you handicapped by reliance of HA performance in a time critical scenario.

HA in general is pretty good, but I’d be reluctant to depend on it to switch a geyser off quickly if the load approaches the limit of your inverter. Leave that to your current working and tested implementation, but add the ability to change parameters through ‘middleware’ where time and or availability isn’t critical.

1 Like

The current code will run with minimal effort on a D1 - so I will just move everything there for now.

Moving over to a HA system would have been nice, but it seems not to be an option yet.

Forgive my question but what exactly is HA? (I guessed it stands for ‘home automation’)