I recently has a VeraLite die, and moved things over to a VeraPlus that I already had. Since I was setting things all up over again anyway, I decided to moved from 1.8 to 2.0 as well since it had moved to formal beta. Migration of both has been good.
I noticed an issue a couple days ago where I wasn’t getting updates any longer from my Vera. Looking in the logs, I see this message:
Received command (ON) for item 'LRFtDoorLockStatus' but the connection to the MiOS Unit 'house' is down, ignoring
The why hasn’t concerned me much as of yet. I’ve been watching closely since, and haven’t had any repeats. I’m assuming something got hung up refreshing an items file, etc.
What potentially worries me is it happening again in the future when I’m less vigilant. Anyone have any idea for how to set up a rule to poll the Vera so I can be alerted if this occurs again? Obviously something in the binding can handle this case, as it generated the log entry. Just wondering if it can be tapped via a rule for monitoring?
Thankfully I haven’t run into disconnects. Along the lines of monitoring, you could brew up something where you have a switch on the vera that doesn’t do anything but has a scene to turn it back off. Every once in a while you could have OH turn the switch on and see if vera turns it back off. A kludge for sure. I’m doing something similar between two OH instances using an MQTT switch. My production OH’s rules keep freezing so I have been running my test OH install as a watchdog.
BUT, what I would love to see is a binding or method to create rules that react to log events. That way you could monitor for specific log events and send an email, pushover etc. Of course I have no idea how to make it happen
There are a bunch of internal (MiOS) State-Variables that track the versions of the metadata. Each time I circle back to Vera I’ll pickup these values.
By default, I don’t generate these out with the MiOS Item file generator, so they’re not present in the default Items file but they’re easy to add.
With these, you could periodically check that they’re changing. If they’re not changing, then there is some sort of communication problem with your MiOS Unit.
Here are the variables I’m referring to (I turned on TRACE mode so I could see them in my logs):
2017-04-02 09:55:04.497 [TRACE] [ab.binding.mios.internal.MiosBinding] - internalPropertyUpdate: NOT BOUND {mios="unit:house,system:/LoadTime"}, value=2017-04-02T00:02:44
2017-04-02 09:55:04.497 [TRACE] [ab.binding.mios.internal.MiosBinding] - internalPropertyUpdate: NOT BOUND {mios="unit:house,system:/DataVersion"}, value=116570746
2017-04-02 09:55:04.498 [TRACE] [ab.binding.mios.internal.MiosBinding] - internalPropertyUpdate: NOT BOUND {mios="unit:house,system:/UserData_DataVersion"}, value=116564001
2017-04-02 09:55:04.498 [TRACE] [ab.binding.mios.internal.MiosBinding] - internalPropertyUpdate: NOT BOUND {mios="unit:house,system:/TimeStamp"}, value=2017-04-02T09:55:11
2017-04-02 09:55:04.498 [TRACE] [ab.binding.mios.internal.MiosBinding] - internalPropertyUpdate: NOT BOUND {mios="unit:house,system:/ZWaveStatus"}, value=1
2017-04-02 09:55:04.498 [TRACE] [ab.binding.mios.internal.MiosBinding] - internalPropertyUpdate: NOT BOUND {mios="unit:house,system:/LocalTime"}, value=2017-04-02 09:55:11 D
NOTE: These values will change rapidly during the MiOS nightly heal (eg. 2:00am ish). It’d be best not to trigger off them directly as you’ll drive up CPU.
Instead, put in a cron based rule that checks the value has changed since the last execution of the rule,
Cool. Thanks for the info. I was going to do just add a “device” that I set back and forth between two values, but I like using something already built in better.
