This is kind of a basic question about the Hubitat kernel. Why is it that the frameworks that sit above the kernel (RM 4.0, WebCore, etc.) are not provided with a guarantee that when a device is told to turn on/off that it in fact turns on/off? I've walked the logs and the call returns immediately with no indication (far as I can tell) that the zwave transmission to the device actually made it and did what was expected. Instead, I've seen where people say "the queue is full" or "zwave gets overloaded" with a mere 20 devices and so you have to add delays and all manner of hoop jumping to ensure what you wanted turned on/off happens. Nothing appears in the log by the system to say the device I wanted on/off is actually on/off. Why is this? I would do almost anything to have a call that either errored back to me or blocked until success or timed out or some other way to 'catch' the error. It boggles my mind how this is possible in a system who's most basic purpose in life is to turn things on/off and to be aware of 'what' is on/off.
I don't mean to be negative, I like Hubitat. I switched from SmartThings to Hubitat C7 a few months back because I couldn't tolerate the lag on a large system (I have over 130 devices) and wanted to execute locally to speed things up. I think it can be a great platform, but there needs to be some real soul searching on why everyone that wants to do something with more than a handful of devices has to spend endless hours figuring out why a call to turn something on/off gets 'lost' or who knows what.
Anyway, would love to hear anyone's thoughts along these lines.
1 Like
Device writers can choose to set state when sending a command to a device, or only adjust state when the device confirms it.
@mike.maxwell can comment, but I expect a lot of drivers change state when the device responds with status.
Programs that consume device events (any groovy app, rm, webcore, etc) reacts to the events the driver produces...
HE is multi-threaded, so multiple things can be processing at the same time. It is mutli-threaded to the point that a groovy app (or RM, or webcore) could get two events processing at the same time (ie if the program has multiple subscriptions).
Webcore normally serializes these for a single piston (but this can be overridden with a piston setting). Each groovy app writer would have to answer if this can happen and how they deal with it (or do not deal with it).
I have not seen my self loss of events. I have on occasion seen issues (or helped others with them) but it proved to be a device driver bug (vs. an all platform issue).
Something in HE to watch is running out of memory (there are threads in this forum on how to see memory free) such as http://hubIP/hub/advanced/freeOSMemory
(fill in your hub IP))
There have been issues with C7 and its new zwave stack that are well documented in other threads. I agree this rollout has been less than smooth, but there is a lot of effort (again as seen in thread in the forum) in addressing them. That said I can understand and sympathize with your frustration. One does expect the core platform and built in devices to be solid. I view these issues a bugs vs. architectural issues. That said, I agree when you have instability it sucks.
So I think you will get what you desire from HE, but it will require your patience and understanding....
1 Like
All the drivers that Hubitat provides count on the device being able to report it's state changes when the device changes state. If the device isn't capable of this, due to device software limitations or mesh related communication problems, then obviously things don't go so well.
So when discussing issues related to the above not hapening, it's very important to mention the devices in the conversation.
I just came here to say that your thread title is probably the best I've seen on this site.
Thanks, was looking to ensure folks understood this was not a simple end user question answered with the usual 'did you check this' type answers but a serious deep dive type question eliciting some of the more fundamental foundational Hubitat logic.
I developed both the hardware and the software for real-time systems in a previous life and know these are not for the faint of heart and come with a myriad host of issues that need to be accounted for. So am looking forward to hearing from anyone that is in the know that can answer or discuss some of the details about the inner depths. Like how the queue is handled and what steps are taken and for how long to address items in the queue. What are error conditions from sent zwave packets that don't in fact turn on/off a device or how that is known? Sure the zwave protocol addresses the packet level stuff but how does the Hubitat kernel deal with 'when things don't go as planned' stuff.
1 Like
Thanks Mike. I run about 50+ switches and 50+ dimmers. All zwave plus. All GE. Initially i used the driver specifically for the GE's, but that was not reliable in status of device. So then I moved them all back to the generic zwave appropriate drivers. These generic drivers are 'more' reliable but do not always accurately reflect the status of the device; especially the level of dimmers. I've had to inject a large (about 500ms) delay between sequential device calls to get a 'more' reliable (so far) execution of expected behavior.
Great stuff nh. Just the kind of discussion I'm interested in. See, the topic of device drivers and the example you used is really at the heart of this particular topic space I'm bringing up. Using the device driver that only changes state as an example, when the device confirms it (I'm assuming the Generic Z-Wave Switch and Generic Z-Wave Dimmer drivers do this) then I'd ask what does it do when the device doesn't confirm it? Because I've not seen anyway to know about this condition nor to deal with this. The only thing I can do is code in a delay, run through my devices to see if their status has changed to the expected, and if not, rerun the command on them. This seems like not the best thing to be doing with devices (or the zwave mesh) nor blanketing my code with 'for' or 'while' loops.
Definitely am patient and will keep up with what's going on in this forum. All good stuff.
An application that sends a command, could decide to track if the command event/status later occurs. I expect most applications don't do that, as even if they detect it, then what? But said, it is possible to code that way if one has the need to. This could be done in webcore with variables, and groovy.
