Q: Healthy poll frequency?

[curlyel]

Hi svalouch, thanks for your effort you've put into this project 👍

I'm curious to know, what "poll frequency" you consider being healthy for the inverter. I'd like to feed some data into InfluxDB and publish them to a MQTT broker to get consumed by my home automation system.

So I'd request some of the data points once per minute, some slowly changing values once per five minutes. Is it safe doing so without risking some hickups off the inverters communication interface?

What's your experience with the inverter regarding the "poll frequency"?

Thanks, Curlyel

[svalouch]

Hi, with the current firmware, my rctmon sends an average of 4.4 frames/second with little to no receive errors.

Older firmware more than two versions ago would only manage to correctly answer 40-50% of those, but current firmware still manages to send replies for other devices to all connected clients, so be prepared to receive data you never asked for. I guess one could add an MQTT publisher to rctmon, and I had originally planed to do that actually.

As for the poll frequency, check the calls to DeviceManager.add_ids in the device_manager.py and battery_manager.py files in rctmon. TL;DR: All the fast-changing stuff including error flags are pulled in at once every 10 seconds, some other values that change slowly such as SOC target and MPP once every one or two minutes, inventory-data (name, whether panels and battery are present) once on startup.

[curlyel]

Thanks for your comprehensive reply. Sounds quite reliable though. After reading some posts in the photovoltaikforum I feared some lack of maturity of the RCT firmware regarding the exposed network interface. But your response is quite promising.

I didn't notice your rctmonyet. Means for my use case: It's almost all yet there 👍 Amazing! Seems that adding even a MQTT client to rctmonis feasable alongside Prometheus and InfluxDB which can just publish all the gathered data to MQTT additionally (when enabled).

I have to admit, that I don't have my RCT system yet - just started to prepare myself for integrating it into my home automation system ;-)

So I can't test against a real RCT device yet. But: If I understand correctly, I could run your rctclientin simulator mode - right?

[svalouch]

Firmware: Well, things improved in recent firmware versions as I mentioned, but it still does not implement client sessions correctly: you'll receive answers for the smartphone apps requests and vice versa, for example. That's a big no-no for networked applications, and it seriously complicates writing clients since you have to sift through loads of unwanted data before eventually finding "your" reply. Because of that rctmon will happily accept unwanted replies and just work with the data. The inverter also doesn't seem to completely shut down its network board when it loses battery and solar power at the same time, causing lots of headaches for implementers (e.g. rctmon may become stuck and fail to reconnect). That, plus the baffling lack of any sort of security doesn't make it look particularly mature.

Simulator: That's explained in the docs: simulator. rctmon won't be particularly happy with it initially, since by default it won't indicate that battery or any solar generator are present, so rctmon won't start requesting battery and solar data as it assumes there's nothing present.

You can, however, edit registry.py and add a field sim_data to configure different values. They are static, i.e. won't change until edited and restarted, but you can test some parts this way. It's mainly intended for firing up quick tests without causing issues with productive equipment (we're dealing with electricity, after all).

[weltenwort]

I can only echo what @svalouch has said. The consuming code needs to be prepared to receive responses for requests it hasn't sent. So a healthy amount of error tolerance and robust timeouts are mandatory.

That said, I've been running the Home Assistant integration I wrote using this awesome library for almost a year now without any noticeable negative impact on the system. In order to cut down on the system load and network traffic I sorted the registers into three different tiers of desired timeliness: "Frequent" with a 30 second interval, "infrequent" with a 180 second interval and "static" with a 3600 second interval. The former is used for highly dynamic values that are relevant for judging the system's health while the latter two are used for values that rarely change like discharge cycle counters or serial numbers.

[svalouch]

Alright, let's close this, then. The main takeaway is that newer firmwares are much more robust and can handle quite a few requests in a short period of time, even from multiple devices.