I was putting together examples, and I discovered the problem is punctuation. Commas, periods, colons, etc.
Yeah about other punctuation than comma, I will release a fix to properly encode arguments
But for comma, then it seems to be a Maker API limitation. From what I've understand, here's the flow on Hubitat:
- receive encoded url
/app/1/devices/1/speak/hello%2CWorld - decode url:
hello%2CWorldtohello,World - try to match speak command signature with 2 args
- fail to found signature method (because speak need only one arg)
Some solutions on Maker API side:
- make specific case for
speakcommand - force to use not encoded comma for argument separation and encoded comma after (and changing a little bit the flow I guess)
- ... (I hope a better solution)
For now (before I release the fix), you can confirm this theory with Hello%2CWorld arguments and if it fail on the same way, then it confirm
I can confirm that %2C does not work. Gets the same error. I can live with setting up a function to parse.
version 0.0.32 published
-
command: encode arguments (was partially done) -
command: improve placeholder for COLOR_MAP arguments
1 Like
Commas can definitely be a problem, as they are the delimiter for multiple parameters in the secondary. So if you try to speak this: "This is, a comma", that will cause the error you got, passing two parameters to speak(this is, a comma).
I think I've given up on using Chromecast in HE. The other limitation I'm finding besides punctuation messing everything up is there appears to be a limit on the size of the message. I'll just keep using node-red-contrib-cast, which works fine except the voice is hard for a hearing impaired person like me to understand at times. And I don't see any options to change the voice like I can in HE.
I recently began using node-red-contrib-cast and am not very satisfied because it has such a delay. I may end up with a hybrid approach.
I have a bunch of door and window sensors and I have them sending a 'whoop-whoop' on open and a 'ding' on closed. Simultaneously, I have a Notification go out to Pushover which always arrives first, by a considerable margin. Additionally the 'ding' is often the only sound I hear (after the 'boop' from Casting.)
I have NR logs full of:
24 Apr 08:10:35 - [error] [cast-to-client:31f2bc.6c0] Not able to load media:Load cancelled The request was cancelled (a second load request was received).
24 Apr 08:10:35 - [info] [cast-to-client:31f2bc.6c0] Error: Load cancelled
In other words the two mp3's are stepping on each other.
I think giving up on HE's ChromeCast (Beta) is an option, but it's not like the grass is greener elsewhere.. at least for me. 
TTS is the one thing I am struggling with to find the perfect solution to on Node Red at the moment.
I have tried Google Minis & Echo Dots.
The Google Minis through Cast on Node Red have OK sound quality but has a truly awful whiny female voice and no better alternative English voice options that I could find so that is non-starter for me.
The Echo Dot's are better for choice of voices through node-red-contrib-alexa-remote2 and it accepts SSML for advanced TTS features and sending messages to a group which is useful. But I find all the voices sound very muffled through them. I'm sticking with them at the moment and they do work well, I just wish the voice sound quality was clearer.
With both of the Dot and the Mini I hate that they have LEDs permanently on if you dare to want to turn the microphone off, which I do, as I don't use voice commands at all.
I use Google home mini from node-red. I don't mind the voice - but it is likely different than the UK one (?).
I don't like the delay from command to speech on the mini, but I'm not using it for anything that the 2s or so matter.
:: sigh of relief ::
One less thing "running" on Hubitat for me. I had found a MyQ flow on Node-RED's site and it works great (with MQTT installed). At this point all that is left is Ecobee running against HE.
I took the original flow linked to below and cleaned it up a little it. Please note you have to have MQTT up and running. I also just edited this to add some examples on building your own MQTT message to use from other flows.
The original flow:
https://flows.nodered.org/flow/83f263d6f5f23e53e2aed85b96aadb3e
In trying to understand what was going on, I was reading this as well:
https://unofficialliftmastermyq.docs.apiary.io/
1 Like
For the record, my Atomic Pi docker swarm turned out beautifully. Probably should have just done that instead of the RPi 4 cluster... But now I have both to play with. 
Just need to wait another 24h for the last 2 cases to finish printing...
1st one turned out decent considering I printed in low/fast quality:
2 Likes
That is cool and looks relatively easy to do.. have to see how many RPi3's I can dredge up.. mmmmmmm thx for mentioning it!
Do you think it would be possible to modify your dashboard table flow above such that a table switches that clicking the boolean (option in table node) would switch the switch on/off?
I tried with a quick and dirty attempt, and it didnt work, mainly (I suspect) because it was just the status, and not control. I know it would be possible if I selected every switch, but this would be quicker.
Anything is technically possible.
But since you can't specify the device in a command node input, you would either have to construct the maker api command by hand (via a http call or maybe the hubitat request node), or use a switch on the payload and have all of the hubitat command nodes pre-built.
To construct the http call you need to know device id, if you used id # as row index that is easy (as index is included in the output of the table message). If not I guess you would have to do a hubitat request node with /devices and pump that into a function node or switch+change node pull out the right id.
Also, you would need to know if the switch is currently on/off, so you would want to either store that in the table too, so you can pull it out of the output msg from the table node, or you would need to do a request node to fetch the current state for the switch (after you have the device id handy, as you need that for this request too).
Definitely possible, though.
Many people want the dynamic deviceId for the command node. With the event node I can definitively see use cases to have it dynamic (ex: sorting events by capabilities and trigger command on the right device without knowing it)
I will try to add this feature on the next release
3 Likes
It could be handy, although I haven't had any use case where i "needed" that ability and couldn't do it some other way.
I assume you are thinking that you would match the incoming msg.device to "device" (or something along those lines)? Exact matches only, or regex style?
For the use case above, they would need dynamic "device" input capability on both the device node and command node. (I say "they" as I am not currently using the functionality described)
Oh, and yay, cases are finally all done on atomic pi cluster... The design took seemingly forever to print....
5 Likes
Has anyone found a method to use Speech Synthesis Markup Language (SSML) with Google TTS device? I have used alexa2 palette to do some of it with a Alexa. The cast node doesnt seem to allow it.
I am just trying to jazz up some of my announcements.
,
Hoping to get help to get me over the final hurdle for presence. Following these excellent directions for setting up OwnTracks/MyWebshookRelay I've got everything talking to each other and logging data, but I can't get the Dashboard widget to work
Any ideas on this?
Hardcoded data in the settings = works
No workie:
Passing in a message object with name, lat and long like the instructions say, it simply isn't reading/respecting those values and is showing the map at some default location
Function node to craft the message with test data and showing in debug console:
Settings of WoldMap node (long and lat empty assuming the message will fill it)
But WorldMap is showing default location
It's been a long day, maybe my brain is just checked out this point on something stupid simple that I missed
FYI - I could not get that to work with WebHookRelay. But it works perfectly with MQTT.
I used to use port-forwarding so OwnTracks connected to my mosquitto setup. I was uncomfortable with that so I shut down the port-forwarding and started running a vpn client 24x7 on my phone to connect to a vpn server (formerly OpenVPNd, now WireGuard) inside my home network.
