Do you have hub login security?
No
Great - then you can use the http access node to send a POST request like this:
(obviously replacing the IP address ...)
What would I use as the trigger node for when power is lost via the UPS?
Ahh ..... I don't have a QNAP. Is it running apcupsd? Can you see if there is a directory called /etc/apcupsd?
I don't see that directory right off hand. Here is what the screen looks like on the shutting down of the nas from a power outage it does have an IP Notify section below at which I have my hubs addresses listed, but don't see that it does much for "a notifcation"
Would it be possible with sending a notification to the node red IP address and maybe an http get or something?
I found a way. I broke my cardinal rule of not searching the forum before asking and turns out this has already been accomplished here. QNAP NAS Integrations for UPS Monitoring, NodeRed, Home Bridge, etc
1 Like
any one else have any problem with Node Red not working after the latest hub firmware update. I can see the device changing on the Hubitat hub but it just not transferring over to Node Red? I create a new token, but that didn't work either? any suggestion or idea's on what I can try. Thanks
I just upgraded my C-5 and it seems to be working. Have not done my C-7 yet though. I'll do that in a bit and report back.
Maybe reboot your NR server for giggles.
Thanks I got it working? I was having a senior moment.
1 Like
Not sure if this is a 2.2.7 platform update or a HE Node Red thing?
But ALL my virtual Omni-Sensors in Hubitat now wont take a number from Node Red for Humidity via Maker API. It works for temperature, but not humidity. Nothing has changed for me, apart from 2.2.7
@aaiyar You might find some errors, if you send humidity from zigbee2mqtt to Hubitat.
@bravenel Bruce, you the Maker API expert?
I didn't see a note about this in the release notes, but that said,... Hubitat has said many times humidity has to be an INTEGER, not a decimal.
Maybe they finally changed the virtual driver to only accept integers for humidity. That's my strong suspicion since this just came up earlier this week.
3 Likes
Looks like the attribute type of number (integer) is being enforced.
Edit: Jason types faster....
3 Likes
Well... js/groovy variable type "number" includes floats... 
So I would say they are now enforcing it to be specifically an integer. Just a guess though. @bravenel would probably know if the in-box omni sensor driver was changed, or not, for sure.
1 Like
From what I recall for Hubitat:
number —> integer
decimal —> float
Maybe so, but that is a bastardized colloquialism. And I don't know for sure if decimal is a wrapper for double, or float, but I digress.
In groovy the NUMBER type is a wrapper class for all/any of: byte, short, integer, long, float, and double.
If they meant integer, they should have just used integer - that is a base data type. They chose to make it easy from a coding perspective and just use NUMBER, which I can understand, but then they did not document anywhere what data type individual attributes are - even though they assume/require them to be specific base types elsewhere.
Anyway, it is what it is. This is just something we will have to live with as developers at this point.
Regardless, I did setup a virtual omni sensor, and I am not seeing this same issue if setting it with a decimal from the device detail page. I do see the error over Maker API regardless wehat I send though.
Seems like a bug. I'll start a separate thread.
I do send RH from zigbee2mqtt to hubitat. However, I'm not using any built-in virtual driver, so there are no errors in my logs.
Edit - although I agree that it makes sense for RH to an integer, even if the devices report it as a decimal value.
Are you using the built-in virtual omni sensor driver? I'm asking because I'm not seeing these errors. FWIW, I'm not using the built-in driver.
This is what I do to get my Konke TH sensor data into a Hubitat device
Latest platform. NR 1.3.2. But I'm not using any built-in virtual driver.
1 Like
OK. I can replicate Mike's issue.
If I specifically send a msg.argument that contains a STRING with a decimal value in it (like "22.33"), I get the same error.
For now I would suggest to @mike that he:
- Don't send humidity as a decimal, convert it to an integer
and/or - Convert the string to a double/float before sending it to the node if you really want to keep the decimal.
You do not get an error if you send:
- Decimal value as a decimal (not inside a string)
- Integer value
- String that contains an integer value
As the Virtual Omni Sensor will accept a decimal as an argument to setRelativeHumidity if done locally, this seems like a driver bug @bravenel . Just my opinion, yours may differ - and that's OK. No big deal in the end, as it is easily worked around.
2 Likes
Oh yeah, I remember that now. I forgot about that completely, but that's why I was specifically converting the payload to a number. Also wanted to round it down to 2 decimal places.
