I have a sunny tripower PV inverter which goes to deep sleep overnight. This behavior may raise a general question. How do we handle sleeping components?
Here is my situation. The sunny tripower PV inverter is sleeping overnight. The PV inverter implementation SmaPvInverter can handle this. During sleep channels are invalidated (for example pvInverter0/ActivePower = null) but the component is not going to an error. The problem occurs when I add a PvInverterSellToGridLimit Controller. For computation it uses
pvInverter.getActivePower().getOrError(). Every night this call switches PvInverterSellToGridLimit Controller state to fault, which sets the complete system state to fault, which triggers alarms in our backend infrastructure.
I am not sure, what to do now.
- from a business perspective the obvious way would it be to disable sunny tripower hardware sleep functionality, but that can’t be the solution.
- Within the PV inverter driver I could set channels to 0 (not
null) when sleeping. All controller should be able to handle this
- We could change all controllers to be able to handle
null correctly.
Or do we need something like a new interface/component or channel state sleeping, because in the future a lot more hardware components may be able to sleep?
What do you think?
Hi Christian,
thank you for bringing this point up. This is also a topic we come across regularly and I can think of a number of solutions.
Invalidating the Channels on Modbus Read errors is handled by the Modbus-Bridge (openems/AbstractReadTask.java at develop · OpenEMS/openems · GitHub). This also sets the Modbus Bridge itself to error state (modbus0/SlaveCommunicationFailed). Currently the PV-Inverter component in your example will not even be set to error state. This is a behaviour I am planning to invert.
It should then be up to the PV-Inverter component to decide if it is actually in an error state (i.e. modbus connection is interrupted) or if it is in another known state (sleep mode). If it is certain to be in ‘sleep mode’ I would say the most logical thing is to set its values to zero ant not null, because zero is true in this case.
On a higher abstraction level: You are right, that handling device states on a Channel level is often a problem. One design decision with pvInverter.getActivePower().getOrError() was to avoid a lot of if-statements like isDeviceAvailable() etc. before accessing the data.
There is also an interesting new feature in OSGi 8 Condition Service that such a feature could be built on. To my understanding this would allow us to query a device state directly in the @Reference or in other places. This sounds like the proper OSGi-way of handling something like this.
What do you think?