I've gone from using NR stand-alone to using it in HA docker as an addon (and back to stand-alone). I have run it successfully in both scenarios. One thing (and I don't remember if it was during my initial stand-alone or when I switched to HA addon) was the that the NR version installed was < 1.x. This caused my all sort of problems where some messages would come, but then they'd die the as soon as they hit any other HE node. So for @mrobi can you double check the version of NR you are running?
As for @morningz can you be more specific as to what issue you are seeing.
Think hard!! LOL Did you setup MakerAPI with the HA port or the NR port?
I'm assuming it's got something to do with my webhook settings. I've tried with and without the login info for NR. I've tried both ports.
Does this help ?? I do not expose this nodered to the outside world and have removed SSL and DuckDNS access - and maybe that last line 'leave back door open' I changed...
It's likely very vulnerable now and I should add some bits back into that config but I'm pretty sure it's protected on my Intranet. Change that last entry at your own risk.
Just to confirm my nodered is locally accessible on http://192.168.1.150:1880
and that IP is the host NUC on which hassio is installed - it is not the docker container IP address 172.x.x.x
I added the leave front door open to my config for testing.
I assume 33737 is your HA port.
I wonder if it's because I'm using the HA integration that's using MakerAPI already?
So I essentially have 1 instance going to http://HAIPADDY:8123 and another going to http://HAIPADDY:8123/hubitat/webhook/
You will need to create two separte Maker API applications and setup the 'URL to send device events to by POST' to be different in each one - one pointing to the HA Hubitat integration and one to the nodered one.
TBH that 33737 may relate to another integration .. I forget now.. it's probably this..
So I installed HA via the image method detailed here
I love the idea of the clickable floorplan of HA as well as the remote access through their Nabu Casa service. Plus once I get rolling it looks like it's relatively easy to pull in camera feeds into the dashboard as well. I'm super intrigued by the Telegram bot integration as well
My hope was to somehow leverage Node-RED to have this setup:
Hubitat to add/manage the 70 or so devices (because HE appears to be way easier to manage devices than HA)
MakerAPI / Node-RED / and the Hubitat palette from this thread to funnel/expose my devices to HA as entities
That second point seems to have two ways to do it:
Custom app/drivers here on HE to leverage MQTT to bridge the two. Sorry, I wasn't a fan of the setup, a lot of it just didn't make sense: like for instance, do I need to worry about "homie" at all or not? It also seems to be way too chatty on the network for my personal taste. Ah well, that code may work for others, but not for me as in the end I'm trying to run stuff on the HE as little as possible (as it stands right now, I have MakerAPI installed and that's it).
Trying to go the other way with this custom HA/Node-RED code that has nodes to create entities from other Node-RED nodes. I've actually got this kind of working as shown in the screen shot below as an example: I can actually control my blinds from either HE or HA. Issues with this route include: limited entity types (sensor, binary sensor and switch) and an annoying ghost event that fires closing of the blinds every time I restart HA, which to be honest hasn't been very often, but it has been annoying when I tinker with it.
I kind of got fed up with both those routes and thought I'd get my GoControl Z-Wave/Zigbee stick up and running to see about streamlining things. I've got it plugged into the Pi, HA sees it just fine and I have both the ZHA integration and Z-Wave integrations installed and working with a few devices paired to each radio. But: paired a Sengled dimmer to it, HA had no idea what that was. Paired a Zooz ZEN31 LED dimmer to it, no idea what it was (some custom editing of the Z-Wave config file fixed this, but that is not something I want to be doing on a consistent basis). This isn't the route to go if that is the pain of pairing devices to it.
I was actually trading Twitter messages from Rob at "The Hook Up" today as he was intrigued by a comment I made on his video today talking about blinds. we seem to have the common goal of using HE as the conduit for devices in NR and HA
Maybe I just can't decide what I want in the end, maybe I'm just overthinking things. But I do like to tinker around and I am a huge fan of the concept of MQTT, so I'm still hoping I can get my setup of HE > NR > HA all straightened out.
Here is that custom HA Node-RED palette in action that takes my three IKEA blinds paired to HE and turns them into entities for use in my Lovelace dashboard.
And as you can see here I can see and can control them from either platform which is kind of neat
OK... But if you use the linked integration everything shows up in HA with no yaml written at all... But whatever makes the most sense to you.
Just seems to me if you want all HE in HA, then that integration is EXACTLY what you want?
But if you want to do your logic in Node-RED, then yeah I guess it may make more sense to go to Node-RED first, instead of HE --> HA --> Node-RED --> HA ...
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...
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.
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.
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.
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.
