You're ignoring my whole other post.....
Ryan, sorry.
Really want to read and write to my hub. Graphing is the catalyst to get started but I also will do a GUI, programming (rules), notifications, device watchdog, etc.
I’m not dissing HE, it’s a good platform and does HA well. It’s extremely good at communicating with my zwave devices. It’s I/O costs are low and it has a Zigbee radio.
A while ago my hub crashed and It was recommended that I keep the apps and drivers official HE ones. OK offload the funky stuff.
Do I need to use Labview, no but it will do anything I want it to. I’d be stupid not to let HE do what it does well. The main reason I switched from Vera was the latency of that platform. I have some virtual 3 way switches and will keep those on my controller.
Matt,
I think you should be able to use the Hubitat MakerAPI App to do exactly what you're trying to accomplish with LabView. This really is no different that those who use NodeRed, HomeBridge, or HubConnect to augment the functionality and capabilities of their Hubitat Elevation hubs. As long as LV supports fairly standard http calls to send and receive data, especially receiving unsolicited data from the hub when a device's value changes, you should have very decent performance.
Keep us updated on your progress. Always interesting to hear about these types of integrations. At work, some engineers use LabView extensively for prototyping projects. We usually industrialize the solution on our standard controls/SCADA platforms before going into production. I can see the allure of using LabView for Home Automation, especially if it something your familiar with.
Dan
1 Like
Yes, as I said, you can do all of that. However, if you are going to try and respond to sensor events within labview, waiting for labview to query Hubitat for that change would mean a significant delay in the lag time between the sensor event and the action by labview. You can use other methods, such as the eventstream to have labview receive those values. My point was is that the MakerAPI is only part of the solution you are looking for.
But no matter what your method of implementation, you are going to see a lag between the sensor event and the response from the device simply because the data has to travel to another system and the action has to return to the hub. That is going to take time, even if very small.
I doubt the delay would be significant, as the MakerAPI will issue the Post as soon as the device status changes. Labview running on modern PC hardware with process this data nearly instantly and can send a response back to the hub. Total round trip would probably be under 50ms.
There are many HubConnect users that use one hub for Zigbee and Z-wave devices only, and the run their rules and other automations on a second hub. They all report near instantaneous performance. So, I don’t know why using Labview on a blazing fast desktop computer would be any slower.
1 Like
Really? I find that most of them report significant hub slowdowns actually. I would hardly call that near instantaneous.
I don't understand how you can add 2 network transmissions and 3 additional process in Hubitat and say it will not take longer. That simply is not logical. You can say the increase is not significant in your opinion but you can't say it won't take longer.
Yes sending the data to another system introduces lag/latency/delays. That is a true and fair point.
Whether it is significant or not is for him/her to determine.
Funny story... for quite some time now I've had some test RM rules duplicated in node-red. When my Hubitat HUB is loaded a running slowly, my off node node-red logic actually finishes before my RM rule. LOL.
1 Like
And if that were the last step in the process, it would be faster. But in order for the rule to take some action it has to be sent back to the hub where it will be affected by the same slowdown that is making the rules run slowly in Hubitat.
Also, if you are talking about extremely complex rules/apps, then yes, that might be faster on another system that can process that complex automation more quickly. But I would argue that is true of any system and that your automation is causing the slow-down. I was referring to simple automations...motion lights, timing lights, etc.
Many HubConnect users split the workload of their home automation across multiple HE hubs to IMPROVE performance.
As @JasonJoel mentioned above, I have seen posts by users saying they exported automation logic to another platform and it was actually quicker than Rule Machine or even Motion Lighting. The fact that all of the Hubitat Apps are Groovy, running in a JVM on a somewhat small hardware platform (versus compiled binary code on beefy desktop PC hardware) may explain why things are not instantaneous.
Let’s let @matt1 give it a try and report back his findings.
6 Likes
No, I was talking round trip to see the final virtual switch move. When the hub is bogged down maker API read/write seems to still get through pretty quickly. Aka it seems to be less affected by the slowdown than the RM rule execution and completion.
Now that is to a virtual driver. If it was going to a radio device maybe it would be a wash/still slow. Don't know - I don't have measured data on that.
1 Like
Well, the overhead on RM is very high. But that is to be expected when you have an app that is trying to do everything.
I would suspect it would get in line before all the other radio messages to be processed. Since the radio is a bottleneck on the system I suspect you'd see that affect this as well.
My point is, that when you take processing the actual automation our of the mix, within the hub is always going to be faster. So, for things where speed is important, its better to make them simple and keep them in the hub. Then, the complex, do this only after checking these 20 other conditions, type of automations, yeah, those would definitely be done somewhere else.
Which makes me just re-iterate an idea I had a long time ago...SmartThings+Hubitat. Call it SmartThings Local Edition. All the speed and local control when you need it (Motion Lighting, HSM/STHM) and the power of the cloud when speed isn't a factor(processing logs, controlling schedules, updating your weather). Add a premium cloud component to Hubitat that would give you access to cloud resources similar to those you get on ST and I think you'd have a game-changer. Now, if I was just a little less lazy... 
Yes, I agree with that. So yes, up to the point where the hub decides to slow down, it would be faster to do it in the hub.
That still isn't to say that it isn't fast ENOUGH to do it externally. Only the end user can decide that. Or that it might be EASIER to just do all logic in one place, externally for this discussion, as opposed to doing things in 2 different places (even if that makes the simple automations somewhat slower).
2 Likes
Spot on.. There are a lot of factors to consider... It's reassonable to conclude that connecting two hubs will result in a marginal, but almost inperceptibly slower performance due to the network overhead and need to raise an event on the remote hub. But that's a very, very, low overhead, as in milliseconds. And when using websockets, there's no extra load on the sending hub as it's already writing those events to the websocket.
Having multiple hubs allows for a degree of parallelism that cannot be achieved with a single hub. It enables the flexibility to decide where a time-critical automation like motion lighting can be localized, while other more complex or compute-intensive automations can be farmed out to a remote hub.
It also builds a more resilient home automation environment.. In my case I have three worker hubs, each have Zigbee & ZWave stacks.. Hub 1 has 247 devices, Hub 2 has 198 devices, and Hub 3 has 96. A single hub could never run all of that... A fact that led me to create HubConnect in the first place.
This topology allows my home to weather the ocasional hub slowdown or even crash, affecting only part of the system. It's certainly not for everyone, but there comes a point where a system scales so large a single hub just won't work.
2 Likes
Project started.
I'm sending commands to my hub from my web browser.
http://192.168.1.225/apps/api/290/devices/[Device]/[Command]/[Secondary value]?access_token=XXX
With [Device] = "195"
[Command] = "on"
[Secondary value] = ""
Hub returns:
{"id":"195","name":"Generic Component Metering Switch","label":"Zooz Double Plug2-LEFT Outlet","attributes":[{"name":"energy","currentValue":0,"dataType":"NUMBER"},{"name":"power","currentValue":0,"dataType":"NUMBER"},{"name":"switch","currentValue":"off","dataType":"ENUM","values":["on","off"]}],"capabilities":["Switch",{"attributes":[{"name":"switch","dataType":null}]},"Refresh","EnergyMeter",{"attributes":[{"name":"energy","dataType":null}]},"PowerMeter",{"attributes":[{"name":"power","dataType":null}]},"Actuator"],"commands":["off","on","refresh"]}
and by the time I look at my app the dashboard says it's on!
In Labview setting up comms is the hard part. Now comes the grunt work.
I am going to have to find a way for my hub it initiate comms, i.e. look at me I have something to tell you.
Do you mean...
"Find a way for LabView to allow unsolicited communications from the Hubitat Hub?"
OR
"Find a way for Hubitat to send data without needing to be polled via Labview?"
The latter is definitely possible via the MakerAPI with its recent feature enhancements. The former...no clue!
This is my exact setup and I notice no noticeable latency, and have zero hub slowdowns.
EDIT: Actually 3 hubs: A Zigbee, A Zwave, and A Coordinator
1 Like
This thread was supposed to be about MakerApi.
Since it's been hijacked I'm done.
3 Likes
And that's what I was worried would happen... 
... Sorry this thread got hijacked - I was trying to keep it on subject.
@matt1 - please keep us updated on the status of your project. I am genuinely interested in learning how well this works for you. If you feel the need to use a private message, that's fine as well.
2 Likes
Please help us make this community a great place for discussion, by always working to improve the topic in some way, however small. If you need to go off topic, or would like to respond to an individual's point of view, please consider using the private messages or the "Debate Chamber" section.
3 Likes
