Quite a number of my ping nodes are no longer working, they show "false" meaning not present, when they are. Only some of them though. They show presence for my network devices, including Unifi.
I wonder what happened. Anyone else?
Does anyone know of a way or have they tried interfacing motion sensors that directly and only communicate to Alexa, such as their Echo Flex PIR Addon sensor, to be used as a trigger for a flow?
I thought up a roundabout way using the alexa remote2 nodes, where a motion detected with a routine would trigger that device to say something and likewise a no motion detected would say something else. This allows the activity to be pcked up by the On Device Activity trigger node in remote2, then I go from there to do the normal motion lighting logic. But I was hoping/wondering if there was a more direct approach.
Dunno. I have 15+ pings setup to poll every 5m, and they are all working.
1 Like
Are you using fixed IP addresses? My phones kept doing this until I figured out Android used random MAC addresses, so the fixed IP wasn't working. I had to turn off the randomized MAC.
Wow, I've wasted a lot of time in Node-RED over the past year, but nothing like this madness lol.
Finally got a nice configurable Alexa TTS/Notification setup where I can send a pretty simple MQTT message and it's super flexible to handle the different voices, whether our not to announce (beep before test) or not, whisper, automatically whisper if my mode is "Night" and use some Home Assistant helpers to set the default voice and test the combinations.
This was a major battle but it's done and perfect for my use. I'm connecting my stuff to Alexa through the pretty excellent "Alexa Media Player" integration in HA. Not more Alexa2 for me.
This might be of use to anyone who wants to arm/disarm Arlo from Node-RED...
It needs work to get motion/audio sensing to work and the node should also support streams and images but I also cant work out how to make those work. Over to you smart people 
2 Likes
I found a minor webhook issue when adding my C7 to NR. In maker I set up the webhook to look like this:
http://{nr ip address}:1880/hubitat/webhook_C7
Then in the NR Config I did the same:
I kept getting errors like this:
When I set the webhook URL in NR to lowercase it started working. Dunno if this is an HE issue forcing everything to lowercase or an HE Nodes issue but thought I'd mention here in case it's already been addressed before submitting a report on Github.
Clarification: In the Maker API config I left the "C7" in the URL in uppercase and changed it to lowercase only in NR. Everything appeared to work fine but was uncomfortable with that so changed everything to lowercase.
1 Like
This should be easy for the pros... I'm playing with the Unifi node but getting object Object error, I'm just outputting to debug node.
Dunno. My unifi gear is on a different vlan from my node-red, so have never used that node.
Are you still on controller v5.xx? Or have you upgrded to v6.xx already? Might not work on v6?
I'm on 5.12.35. I have an old install of node-red-contrib-unifi (0.0.6) that worked when I tried earlier but the new one 0.1.15 is giving me that object Object error.
I found that error when either my IP was incorrect or user/pass error in the config
I tried so many different combinations, I will try that again tomorrow. Enough messing with it for tonight.
Oh yeah you are absolutely right, the config doesn't allow to have uppercase for the webhook URL path. The only reason is to follow good practice about URL path
- avoid indexing issue
- interpretation from windows vs linux server
- probably other stuff if you google it "uppercase vs lowercase url path"
But honestly these reasons doesn't matter here, I only force thing to avoid to test all possibilities and help user to have a valid URL. Then if you already test it, I have no objection to change the regex and allow uppercase 
1 Like
I usually do all lower so it never occurred to me that this could be an issue until I decided to add the C-7.. I'm good either way but you might want to do it for completeness since HE Maker accepts upper/lower as well.
Thanks again for all your great work!!!!
Fixed in 1.3.1 
- allow to use uppercase in webhook path
- improve log to add node ID even if node has name
8 Likes
Hi
Awesome work with the node types. I've been linking some modded IKEA controllers to Hubitat through deconz (Conbee 2 on rPi) using nodered. I have some suggestions to make the linkage more scalable.
As it stands, I have 3 5-button wall mount keypads that I want to link to Virtual Buttons. Sounds easy, but at the moment, I need to create 45 command nodes to accomplish that.
So here is my suggestion: Have a custom input option for the device and command fields, and make them (along with the arguments) TypedInput fields. That way, in stead of 45 command nodes, I can do the same with one command node and a few switch/change nodes (or a function node if I want to get fancy), all without losing any existing functionality.
I'd be happy to do the work, but I'm a crap developer
Anyway, great work
If I am understanding you correctly, you want to be able to override the Device, Command & Argument fields by sending those values using a Change Node. If that's the case, you can already do the Command & Arguments portion. According to the Change Log, I believe what you are asking was implemented in Ver 1.0.0 for the Device also but I have never tried it to confirm. I have definitely overriden Commands & Argument fields
From: node-red-contrib-hubitat/CHANGELOG.md at master · fblackburn1/node-red-contrib-hubitat · GitHub
3 Likes
Yup.
2 Likes
Ninja'd by the best people!!! 
1 Like
On the command node, sure. But isn't he asking about the device node?
Just read it again and he is saying both. I'm not where I can check but I don't recall seeing this capability on the device node.
1 Like
