For every switch/dimmer in my setup, I may have up twenty or more conditional counters which I use to track the change vectors for the switch (i.e. direct physical manipulation, cron, TOD, habpanel, remote via myopenhab/IOS/etc, etc.) (I do this via various combinations of proxies and grouping.)
Because not every change vector occurs for every device, I dynamically created the counter items when the relevant change vector gets hit and add the new counter to a Counters group which is automatically persisted. Otherwise I have to statically declare a metric-boatload of items.
I have a Member of Counters changed rule which routes the latest values over mqtt to a consolidated viewing console spanning multiple sites.
This all works fine in a “steady state” BUT there is a problem which occurs at startup. Because members of Counters are persisted and I have Restore on Startup, what happens is that after startup events are not forwarded over mqtt to my consolidated console. The Member of Counters rule fires and logging indicated that the mqqt writes occurred, they in fact do NOT occur as determined by watching with MQTTFx. After considerable poking the beast, I can confidently state that the appropriate function is restored IF I edit the Member of Counters rule file and make ANY change to it at all, including adding/deleting a blank in a comment. A simple TOUCH of the file does NOT restore the functionality – it has to actually change even trivially.
It seems to be that the restore on startup of values from prior dynamically created counters is interacting somehow here but I am a bit stuck for a solution other than an EXEC rule which does ‘echo " " >> {member of group rules file’ after startup completes.
Which version of OH and which MQTT binding (v1 or v2?)?
Are you calling sendComand or using the MQTT Action?
I think there was a feature added in the past months that looks to see if the file is actually different before reloading it. It’s a reasonable check to have give how long it can take to parse the file on RPis.
I have noticed though that you can force a reload by changing the permissions on the file.
Given you are using MQTT, I wonder if using retained messages might be a more appropriate approach anyway instead of restoreOnStartup. The messages will persist and if your remote clients disconnect and reconnect the most recently published retained message will be republished to them when they reconnect. Similarly, when OH reconnects to the broker, it will receive all the retained messages on those topics that have retained messages and update the Items accordingly.
This way there is no need for the Rule at all, nor the need for the restoreOnStartup on those Items either. And everything gets initialized with the most recent values when they reconnect to the broker.
Based on the very limited information presented, it appears that using retained messages instead of restoreOnStartup would be a more appropriate way to keep the count persisted over OH reboots. And if you use retained messages, you don’t need the Rule at all. The restore is handled by MQTT itself. You just need some MQTT Things defined to both publish and subscribe to the topic and treat the incoming messages as an update, not a command or else you end up with an infinite loop.
