Ecstatic.
Heeeey!!! Too much noise on this channel that I watch.
Take it outside and let's focus on cool stuff we can do (or bugs to be fixed ) with this app.
4 Likes
1 Like
If you plan on using ffmpeg as a conversion source for the camerastream attribute, the most efficient solution is to have the cameras sub-stream produce a h.264 (it can be h.264h) stream with AAC audio, and then use this from a command prompt (changing STREAM to match your RTSP stream and PATH to match the output path of the webserver. It is currently set to -r 7 to match my cameras fps=7. You can change that "7" to whatever matches your cameras. I found with this set, it stopped a lot of the drops/buffers that Google experiences due to RTSP jitter in the ffmpeg stream:
start ffmpeg -nostdin -hide_banner -nostats -loglevel panic -use_wallclock_as_timestamps 1 -r 7 -rtsp_transport tcp -i "rtsp://STREAM" -preset ultrafast -tune zerolatency -c:v copy -c:a copy -hls_time 3 -hls_list_size 10 -hls_flags delete_segments -hls_start_number_source datetime -hls_allow_cache 0 "PATH.m3u8" &
"start" spawns a new cmd window, which allows you to create on batch file with many ffmpeg commands for each camera. The "-nostdin -hide_banner -nostats -loglevel panic" and ending "&" allows it to run in the background. The rest basically does a clean copy of the video and audio streams (hence why the camera needs to be in h.264x mode with AAC).
If you have a non-h.264 feed (such as MJPEG), you can do this to convert it (just replace with the source:
ffmpeg -nostdin -hide_banner -nostats -loglevel panic -use_wallclock_as_timestamps 1 -i "NON H.264 STREAM" -preset ultrafast -tune zerolatency -c:v libx264 -b:v 256k -c:a aac -b:a 8k -hls_time 3 -hls_list_size 10 -hls_flags delete_segments -hls_start_number_source datetime -hls_allow_cache 0 "PATH.m3u8" &
Hope this helps someone who is struggling with generating a decent stream source.
2 Likes
This is a great add-on app and while I was able to get it installed, integrated, and for the most part most things working the locks and fans I can’t get working. I'm hoping someone can help me with them and TIA.
I've set up 4 different device types in the app (dimmer, switch, fan, and lock). I'm hoping to use this integration instead of both it and the standard HE. Each device type is configured in the following way
- Dimmer: DType- Switch Level > GHDType - Light > DTraits - Brightness and On/Off (added the on/off state when I realized no on/off button in the Google Home app only a slider)
- Fan: DType - Fan Control > GHDType - Fan > DTraits - Fan Speed
- Switch: DType – Switch > GHDType – Switch > DTraits – On/Off (I originally had the GHDType set to “Light” but none of the switches would respond after the first time/use. After changing to switch in the GHC app I then changed the switches to Light switches in the Google Home app. This fixed the not responding error and now the light switches work perfectly)
- Lock: DType – Lock > GHDType – Lock > DTraints – Lock/Unlock
I use an assortment of zwave devices in each category as well. For both dimmers and fan speed controllers I use GE and Lutron dimmers/fan controllers. With regular on/off switches I use GE and Inovelli. The Lutron switches seemed to work without any hiccups but the GE and Inovelli I did have to make the changes I mentioned above to get them to work. The lock is a standard Kwikset zwave lock that Vivint provided but I no longer have their service so use it with Hubitat on my back door. I have a Yale on my front door.
The issue I’m having now though is as mentioned I can’t get the lock and fans to work. All integrated with GH and show up in the app but all also have the cog wheel in the corner with no way to adjust their state. Making inquires via Google assistant only yields the “that devices isn’t set up” error. Any ideas on how to get the fans and locks to work? Thx
1 Like
You probably want the On/Off trait as well. That will give you an On/Off button in the Google Home app. The app UI doesn't support the fan speed trait. Fan speed can only be controlled with voice controls.
Similarly, I don't think the app UI supports locks. You should still be able to control them with voice controls. If that's not working, turn on debug logging in the Hubitat app and watch the log when you ask the assistant to lock or unlock one of your locks. You should see the EXECUTE request. If there are any errors post them here and I'll take a look.
The thing is when the Lutron hub is integrated directly with Google Home and not through Hubitat fan speed control works fine through the UI, but, it is what it is. I already had the on/off trait for the fan setup but it didn't make any difference in the google home UI, yet. What's frustrating though is that the voice command works to change the fan speed but whenever I ask google to turn off the fan using the exact same syntax it says the device isn't setup up yet.
Oddly, the voice control for the fan and locks decided they wanted to start working now so at least they're good to go with the exception of the fan off state. The lock seems to be hit or miss in terms of actually working.
Can you screen shot this? Is it using the brightness trait to control the fan speed?
I stand corrected, it only does on/off state after integrating lutron directly. For some reason I thought I remembered it having speed control. What I was actually remembering was how I set up my routines via the custom command that allowed me to set the fan speed but that's basically mimicking the voice side. That being said, after integrating lutron directly it forced a change to the fans state via hubitat. It's now showing up with an on/off state so I removed the lutron integration. At this point I'm just troubleshooting the door lock inconsistency.
Just a suggestion: once you do get locks working, you may want to add a PIN, to keep stranger form yelling in the window: "Hey Google, unlock the door".
1 Like
You are correct. Locks are only voice control in the app, but are an open/close + pin entry on the nest hubs.
I can ask google to unlock, and it requests a pin (if you turned that on).
I went to set this up, and found that in your Setting It Up section the link to the code didn't have a link behind it. I found it anyway in your repository but I expect you'd like to know and fix it 
Heh, must have missed that link when I copy/pasted the post from the readme. Fixed.
How do you do that?
Right... I now have a linked service called "[test] Ginger cat". I didn't want to call it Ginger cat but it was refusing all the more sensible relevant names. The linked service came with a virtual switch which I can turn on and off from my phone in Google Home, so I guess the installation worked. What I want to know is how do I get rid of the [test]? And can someone suggest a name? It won't allow single words apparently.
You can't get rid of the "[test]". I personally use "Hubitat Community" as the name for my Google Action, but the name doesn't really matter. The only time it comes up is if there's an error; the Google Assistant will say something like "Sorry, isn't responding, please try again".
Ah ok. Well the devices look normal and interact normally anyway, that's the main thing. Thank you for your work!
For some reason everything went really smooth with the installation and everything is all set except the commands don't actually do anything. I'll tell Google to turn on the light and within the Google Home app the light is shown as on but the light doesn't actually turn on. Same for all other devices.
Any idea why?
Interesting; I'm not sure what could be causing that. If you turn on debug logging in the Hubitat app, do you see the requests in the Hubitat log? If so, are there any errors along with them?
Thanks for replying, let me try and remove everything and start over. If I have the same issue again I'll look at the logs. (If you don't hear back from me then this worked).
