That worked it actually played something and provided the following debug.
But just like @stephen_nutt it says %20 in between every word where there is a space.
No hurry take your time, fantastic work so far!
1 Like
@fblackburn. I've just updated to the latest version and wanted to thank you for all of your efforts with this. 
I really like the new attribute selection drop down for device nodes - I think it makes it a lot easier for relative newbies like me to understand and get working. Also the device status appearing below the node is a great help in seeing what is going on.
Thanks again.
3 Likes
I agree. And it really simplifies the layout of the flows.
@fblackburn Just saw this and it intrigued me. This was the route I chose when I was using NR to help with my slow and methodical migration to HA. I don't know much about which way was better but based on my experience and the little I read, it seemed like a better option than Maker Api.
Here are my perceived advantages from a layman's perspective:
- 2 way communication with the ability to force a socket reconnect.
- HE hub is already pushing this data out so the load on the hub would simply be in maintaining the socket.
- When pulling data on a large number of devices through Maker Api, I noticed a significant impact on the hub's performance. This was many firmware revisions ago so I can't speak for the current state.
Perceived dadvantages of socket:
- NodeRed server would be under greater load because it wold have an open faucet of events streaming into it, whether it was info you wanted to capture or not...event filtering would have to happen in NR rather than HE.
Again, I'm far from an expert on these things but my gut tells me that websocket is the way to go, so I'm truly curious about your thoughts (and those of our resident experts) on going this route.
I started out with the Websocket connection when I developed the Homebridge plugin. MakerAPI didn’t have the POST feature at the time. The Websocket connection works fine and well, sometimes I had problems with reconnects when the hub rebooted.
However, there is no speed or load advantage that I have seen. I switched the Homebridge plugin over to the POST feature and it still works that way today.
If you ask me, stay with the POST feature. It is supported and as fast....
1 Like
Thanks Dan.
Yeah..there wasn't the POST feature when I was doing this either so I had to request updates manually. Good to know...Thanks for the feedback.
Thanks. I've had a look at this, and figured out my problem. I didnt use any wires into the previously "saved status switch" (what you call Saved Pattie Poehl status to Boolean). The wire doesnt need to be from the node that saves the status to the "saved status switch", it can be from anywhere, as your flow is set up. But there needs to be a wire. (I presumed a change in the saved status would automatically flow through even without a wire). In my flow, it was at the start of the flow, and nothing was ocurring, because there was no input/timestamp.
This leads me to another question, that I've been mulling over for a few days.
Let's say that the saved Pattie Poehl saved status is false, and M-CR is active (let's assume it's a motion sensor). And so the node "Saved Pattie Poehl status to Boolean" acts as a stop sign in the example flow (above) when M-CR is active. But then Pattie Poehl changes to true. And the device M-CR is a motion detector and it's already active. It seems to me that the flow would not run, because M-CR is already active.
It seems to me that the only trigger in this flow is motion. Is that correct? It's checking in with some other saved status, but will only ever trigger the flow on motion. Not a big deal, because the timeout is only three minutes.
On another note, I'm going to utilize ("steal") a lot of your example code/nodes!! Thanks.
1 Like
I think it will run. At least my motion sensors (Xiaomi Mijia) seem to flip transiently from active to inactive before becoming active again.
The node "mike - active/inactive" is copied from you. So copy away. The best thing about Node-RED relative to RM is that sharing automations is so simple. We should totally be doing this ....
Sharing is good. Another thing that can be handy is if you have many similar automations in node-red - make a sub-flow template. Can save yourself a lot of node dragging around.
That really only helps, though, if the set of nodes are the same each time - and all inputs to subflow have to come into the same node, which limits where it can be used too.
2 Likes
Importing shared nodes is how I learned NR initially. There was a lot conceptually I didnt understand at first and by copying and customizing node flows from our veterans, it helped piece together the missing links in my brain. @dan.t, @btk and @corerootedxb all provided great learning templates for me with their HE performance monitor flows. Once you get the ball rolling, you realize that NR is one of the deepest rabbit holes for automation. SOOoo many ways to integrate and accomplish almost anything.
2 Likes
I agree; like if you have a bunch of Pico Remotes! Copying flow of one Pico and pasting to control another Pico in a different room is easy. You just have to update a couple of nodes but the logic and layout is same. It's much easier than writing similar rules over and over again in HE.
It took me a very small fraction of time to move all of my RM lighting rules to node-red than it would have taken to re-make them in RM. All because of copy/paste and quick mods/updates during troubleshooting.
For me the main draws to having logic in node-red, regardless of whether it is faster or slower, is:
- export capability
- copy-paste
- Rapid modifications/updating
- No code needed normally, although code can be done easily when needed
- Near platform independence from the device source
While I couldn't use my Hubitat lighting flows exactly/without ANY modification in Home Assistant or an MQTT device, it is a trivial modification - typically just replace the in/out nodes.
As someone that has used Homeseer, Vera, SmartThings, Hubitat, Home Assistant - and others I'm likely not remembering - and had to re-do the logic every single time platform independence is something that REALLY resonates with me. That is why I don't just do the logic in Home Assistant, even though the Hubitat to HA integration is pretty good these days.
Fast forward a few months and some company releases a Z/IP based zwave 700 hub... I'm good. If I decide zigbee2mqtt can work for my device needs... I'm good. If I want to incorporate some of my new LoRa/LoRaWAN devices I'm tinkering with into my logic... I'm good.
If I can get it into MQTT or there is a direct node-red integration, I can use the device in my logic. THAT is power to the people. 
2 Likes
100% this. This is #1 on my list. As I'm currently shopping around for another platform that handles zwave better, the one thing that kept me held off was having to re-write all the logic once again, and then trying to tie whichever platform to hubitat so that everything is working together.
Node Red makes this possible. Now knowing all my logic is permanent and won't have to ever be re-written again, also knowing that any future platform update won't introduce a bug into my logic, is a big stress saver and opens up so many more options to join in my overall home automation experience.
1 Like
Well, after some tests, it seems that Maker API does not decode URL for arguments, which cause you the space problem (%20)
I guess that %25 does not show you error but don't say the right thing
Here some explanation about encoding URL: HTML URL Encoding Reference
It works well for the postUrl (ex: http://192.168.2.50:80/apps/api/100/postURL/http%3A%2F%2F192.168.2.32%3A8080%2Fhubitat%2Fwebhook) but not for arguments.
When I try to encode the secondary value from the command:
- template from doc:
http://192.168.2.50/apps/api/100/devices/[Device ID]/[Command]/[Secondary value] - not encoded:
http://192.168.2.50:80/apps/api/100/devices/1/setLevel/10,50: OK - encoded:
http://192.168.2.50:80/apps/api/100/devices/1/setLevel/10%2C50I got the following error in Hubitat log
java.lang.NumberFormatException: For input string: "10%2C50" (setLevel)
Allowing commas in the URL path (or any not encoded char) is a bit awkward (from developer point of view), but understandable if it is to be used by non-technical/general users (easier and can handle simple use cases). However, it's quite limiting when it comes time to enter arbitrary string/sentence.
A quick search shows that someone already mentions this issue:
I don't have any device to test with sentence:
- You need to open an issue to Maker API
- I need to have the exact URL format it takes to work from the API
I am one of these people
I'm not sure how to do or what is being asked for here. (from being one of these people)
Hopefully someone who has more experience can chime in.
I will confess you that I didn't read a lot about Hubitat's websocket and how it works.
I've chosen webhook only because it was officially supported, nothing more.
The following answers are only my opinion/preference
The main advantage of websocket is that servers don't need to be reachable by both sides. If Node-RED is behind a NAT, then is simplifying the configuration. But I don't think that facilitating complex architecture is the priority of Hubitat (which is fine).
For this plugin, it will remove the awkward webhookd configuration section that nobody understand (without reading doc) 
A disadvantage of the websocket is to maintain the connection and handle reconnection. For all other performance issues, we can often improve the code and the desired performances depend on the use cases
I don't like this kind of architecture. I prefer separate events (weboscket) from commands (API).
True. Does the websocket is authenticated? Even if the websocket is already used internally, it's maybe not ready for being used by other external components
Do you talk about the initialization process of requesting all devices data? If yes and someday, it cause issues on this plugin, then there are probably some improvement that can be done on the plugin side (ex: requesting only one device for all the same device node).
True, but without any metrics I will not be too worried about this. 
I saw argument about that using a lot of webhooks can decrease the hub performance. Then I would say that if you want to have more than 10 (which is an arbitrary number) webhooks configured, just proxy it in another tool and use your own broker.
Anyways if one day, websocket become official, it should be authenticated (if not already) and maybe add the ability to filter events by event types. Meanwhile, we can also make a websocket node to receive all events (those we cannot have with webhook) and use both (websocket/webhook)
3 Likes
How do I convert a rule like this to NR? Is there an equivalent of a Private Boolean in Node-RED? Or should I just use a Hubitat virtual switch .... (are there virtual switches that can be created in Node-RED?).
Use a flow or context variable or a virtual switch in Hubitat like you said.
It would really be a global, flow or context variable. Then check/set the variable as needed with function node or switch + change nodes.
1 Like
I'm really loving the new attribute status below the node, but I'm finding a few HE device nodes dont actually display the selected attribute. For example, the contact sensor below is not showing.
It's been deployed and injected. I had the same with a Hue bulb, but that seems to be working today.
1 Like
Thanks, I'm going to go lookup how to create/use context variables.
