Node-RED nodes for hubitat

[morningz]

As of this morning, I'm down to 3 apps left on my Hubitat (to talk to garage door, presence, and ecobee)

I turned off the app that auto reboots the hub every morning a week ago, it hasn't needed it, that's been nice!

I'm still fighting with some things, like for instance the combination of light switches and motion sensors in 3 different rooms, I think I just may be overthinking them (i hope!). there has been nothing worse than walking into a room wondering why a light is already on lol

But getting closer....

[stephen_nutt]

@morningz

there has been nothing worse than walking into a room wondering why a light is already on lol

Your wife walking into a room and yelling at you that the light is not turning on is worse.

[Geoff_T]

Has anyone found a way of getting TTS with a good choice of voices on NR?

In Hubitat I use "Brian" who sounds like a traditional English Butler. We like that, and the whole automation system is now referred to as Jeeves. So I want to retain his voice for all TTS both to Google Minis and Sonos Play.

SonosPollyTTS allows the "Brian" voice for the Sonos, but I couldn't find a way of getting anything other than an especially whiny female voice via Google TTS. There is PollyTTS but that just gets the TTS as a file that doesn't pass to the Minis. At the moment I still fire all TTS commands back to HE and get it to do the output, but that means replacing all spaces in the string with hyphens so it's a bit of a pain.

If an all NR solution is available I would much prefer it.

[stephen_nutt]

Have you looked at SSML (Speech Sythesis Markup Language)? The Alexa palette I use allows for use of it. However, I cannot get it to work using the Cast palette to my Google Mini but this page on Google's website seems to indicate it is possible:
https://cloud.google.com/text-to-speech/docs/ssml

[Geoff_T]

@stephen_nutt

Have you looked at SSML (Speech Sythesis Markup Language)?

I haven't, but it looks interesting. Thanks for the tip, I'll have a play.

[stephen_nutt]

If you get it to work, you have to share. In my short research, it would seem that a node from this palette, node-red-contrib-google-tts, sending to a cast node, node-red-contrib-cast, should work but I can't figure it out yet.

[aaiyar]

Mapping using the OwnTracks and worldmap nodes is pretty neat. Works well enough to map my movements within the building I work in. It shows in my office and also indicates most other rooms that I was in this morning - except when I was out of cell/WiFi range (the building's a concrete behemoth).

[erktrek]

Sadly I've maxed my internal limit on superlatives thanks to all this NR stuff so suffice to say

[fblackburn]

@mike

How to refresh the palette so it updates. (I know how to update, just NodeRed not showing an update for Hubitat, it's still at 0.0.29)

Here's the chain to follow when a new version is released

1. I check that changelog is updated
2. I push a new tag on github
3. I publish the package on NPM
4. Node-RED servers need some time to sync the package with npm
5. You refresh the browser to see the update

if you wonder why the version is not available, you can verify all these links to see where is the update (probably stuck on step 4)

@JasonJoel

"Whichever approach you take, you will need to restart Node-RED to load the updates."

Yeah I confirm that you can install new nodes without restarting Node-RED, but it's impossible to load updated nodes without restart. It's a technical limitation

@erktrek

@JasonJoel also gets huge thanks as well for all his discussions on NR over the past year or so (maybe more!) - very interesting and informative. Totally inspired me to try it out.

Yeah so true, I would dedicate a lot of releases to him, but I wouldn't want to make others jealous

[fblackburn]

@erktrek

Would like an "** ALL **" (or something similar) option added to the "attribute" dropdown. Once selected you would then have the option of either choosing "send selected event" or "send all events".

You can already do this by selecting Undefined. You will receive all events

I know that Undefined label can cause some confusion, but this field do two things

• define which attribute you will get when the node receive an input message (to know which attribute to send)
• define which attribute is sent to output when receiving an event

But yeah the UX can probably be improved. If you want to start a discussion on github, you can open an issue with some ideas

[erktrek]

I did not know this thanks!!!

[erktrek]

So only the sending of events.. if I wanted to just read all the values at once "undefined" gives an invalid attribute error so I still need multiple nodes of same device / different attributes.

Don't want to clog up the thread here with this stuff so may just submit something on Github.. appreciate the responses.

[JasonJoel]

@fblackburn

You can already do this by selecting Undefined . You will receive all events

Just note, though, that you only receive the attribute for the event that was sent. It does not send ALL ATTRIBUTES each time it sends an update.

It sounded like you may want it to send all attributes all at once, and that isn't what it does (from my recollection).

EDIT: Doh, you ninja'ed me @erktrek .

[fblackburn]

Ah yeah you're right
Yes if you can open a issue to support it. I will try to see what I can do

[JasonJoel]

@erktrek

So what you really want is the equivalent of:
Get Device Info (replace [Device ID] with actual subscribed device id
http://[Hub IP]/apps/api/[Maker API app ID]/devices/[Device ID]?access_token=xyz123

You could use an http request node to do that, but I understand you would rather the hubitat nodes have an option to do that.

[erktrek]

Interesting... yes that what I want and yes that might be a way around it. I'm good with an NR solution but it would be nice to keep it within the palette..

[JasonJoel]

Like maybe some input msg flag that sends everything in the cache. I can see a few uses for that... Deciding on the format of the payload would be interesting though.

I would vote for:
payload: {
attribute name 1: value,
attribute name 2: value,
...
}

But if we think we need dataType, etc, in there then it would have to be something similar to how Maker API returns the values, in an array. The bad part about that is that Maker API returns it with just an indexed array, so you have to check each element of the array to know what the attribute type is.

This is the Maker API response format. The array levels being indices are annoying:

If it came down to an array, doing it like Maker API could work - but with a twist... Just use attribute name for the array tree level instead of "0", "1", "2", etc. I "think" that is possible...

Then users could just do msg.payload.level.value or msg.payload.switch.value, etc. And not have to search or walk the array to find the value they want.

Something like this for msg.payload:

{
    "level": {
        "value": 50,
        "dataType": "NUMBER"
    },
    "switch": {
        "value": "on",
        "dataType": "ENUM"
    }
}

[erktrek]

Maybe like an info node or something. Yeah I was thinking an array in the payload dunno if thats a good NR way of doing it though.

edit: Ninjad by JJ!!!!!! like your idea.

[JasonJoel]

@fblackburn

Yeah so true, I would dedicate a lot of releases to him, but I wouldn't want to make others jealous

Bah. You are doing all the real work. I'm so lazy I haven't even been issuing PRs like @dan.t has.

[fblackburn]

Yeah the list is annoying to parse .. it was on my todo list to change the way to store internal data exactly as you propose. And I think it's a good idea to expose it like this

@JasonJoel

Bah. You are doing all the real work. I'm so lazy I haven't even been issuing PRs

Considering that it takes me 10 times longer to write in English than writing code, then your help is a huge contribution of real work