ooooh wait a second... you may be on to something here.. if that integration ports the HE devices into HA as entities, then NR can just be used to mange rules and automations against HA entities...
I know what I am reading up on tonight!
That's exactly what it does.
Then you could still do HA --> Node-RED with their node set if you still want to do logic in Node-RED. Would be slightly slower, as the HE data would have to double hop, though.
The integration takes about a minute to setup. Just make a new Maker API instance in HE, and go to town with the instructions in that thread.
If you make another Maer API instance you don't even have to dismantle your current HE --> Node-RED integration.
1 Like
There are HA nodes for nodered too if you want and also MQTT will provide a bidirectional HA<>HE device mirroring but I think you would be suited with the HA Hubitat integration (HE > HA) if you don't specifically want nodered or HA devices into HE.
sorry behind relative to Jason's posts...
.
Wow... thanks so much, this is EXACTLY what I needed. It's fantastic that so many types of devices are available as well.. perfect!
Starting tomorrow it's time to blow everything up and start over! lol (not the first time, probably win't be the last time either)
This is exactly what I'm using. The HE integration for HA brings everything into HA as entities, and then using the HA nodes in node-red to do all my automations. The only thing that's missing in the integration right now is hub mode and hsm but the dev is going to be adding them in a future release. That's why I'm looking at getting the HE nodes going is because I want to finish ditching rule machine and I'm impatient LOL
There's also an HE-MQTT addon that you can use to bring HE devices to HA and vice versa. From your post about MQTT this will probably be more what you're looking for.
1 Like
So you see these events from HE logged in HA's nodered addin ?
I thought I got to that point too .. but I played around a bit tonight and I have broken it - now not seeing anything. So you're doing better than me.
Echoing something Jason said earlier I can't see really how this could have worked either. I have another nodered instance - not in a docker and that works with no problem. So I'm starting to doubt that it was ever working - but if you see events - don't play around just use it ! (let me know)
I got one! But now I'm not. Immediately after editing and deploying I got an event. I was all excited and posted. Since then, I haven't gotten anything and can't seem to get it back. 
On initial deployment the node-red node goes and retrieves the status. That is completely different than receiving the POST event packets.
As a container only listens on ports it is configured to, I would expect that somewhere you would need to edit the node-red container to listen on the specified POST url port...
Yes, that's the only way I can get the "mode" node to work is by hitting deploy. Oddly even injecting manually it won't retrieve again.
In my case last night, I deployed, waited for it to connect and then turned on a light. I've got the event node tied to a debug node and it received the message. But that is the one and only one that I received. Call it a fluke.
Manually triggering the input of an existing device node doesn't go out and fetch the value from HE - it just reads the value from the node-red cache and sends it along.
So if the node-red cache isn't updating, then you will just get the same value until the next deployment or node-red restart (which then updates the cache).
Hmm. No ideas there, unless the cache wasn't fully built yet so when it did finish building the new value was available....
The initial cache building is throttled, so if you have a lot of device nodes it takes a while to complete behind the scenes.
Just wondering.. Are there any advantages to having multiple instances of maker api on the same hub pointing to the same NR server?
edit: would it help in anyway with HE-Node initializations?
Hmmm..... Interesting question.
MIGHT be faster on initialization, never tested it that way to see. My guess (as I haven't tried it) is that it wouldn't help much.
Yeah that was kinda my thought too. Is maker async?
I would swear the answer to that is yes, as I'm pretty sure I asked that question before.... But a quick search didn't find anything conclusive - so I could be remembering something else...
Yes and no
Yes: because each config node limit to 4 simultaneous requests
No: because in my tests I already receive errors from HE for more than 4 simultaneous requests (and if you have 2 Maker API on the same NR, than you'll have 8 simultaneous requests max)
Moreover, from my small benchmark, more than 4-8 simultaneous requests doesn't help much, because HE will queued responses. Anyways you can easily tweak code to change the value of MAXSIMULTANEOUSREQUESTS = 4 and do your own benchmark 
EDIT: In fact I don't remember very well what was the ideal simult requests, but 4 was the best compromise with performance and error. Maybe an advance parameter would be useful to configure it, because some people can not care about error on init, because on next input/event received it will try to reinit the node.
2 Likes
So you are saying 4 TOTAL simultaneous requests to NR is the optimal scenario even given 2 maker instances that are supposedly independent of each other? That's interesting to know... might explain some of the slowdown issues if the HE is easily swamped like that or am I not understanding things correctly?
Thank you for the info!!!!! fascinating stuff..
Mmm never tested against two maker instances, but the kind of error incurred when you do a lot of simultaneous requests seemed to a missing lock/corrupted data. So I doubt that adding another instance solve this issue (maybe, but it can also increase errors 
)
But it's only assumption and without direct access to code and/or hub, we can only do assumption.
Also my hub on which I made tests was pretty empty (4-5 devices and nothing more than Maker API). There are probably better benchmark to do and reverse engineering to do to find the perfect number or delay between requests
You can do your own benchmark with tool like Apache Benchmark
Out of curiosity, is it only for the knowledge or the init time is too long?
well I would not call easily swamped because requests are really fast and you need exactly simultaneous requests to cause sometime error ... so I don't know on loaded hub
No nothing like that I was just curious about what multiple maker instances would do.. if it would be more efficient in some way.
The HE nodes are running really well. Thanks again.
1 Like
I have this flow that @stephen_nutt put together and share with me but anyhow I have been trying to get it to automatically restart when it is disconnected. If I inject the function node with Disconnected or Connected it works as it should, but when I connect to the Device Wyze Net Device it does not send the payload to the function node? Am i'm missing something?
