Would it be possible to use the computer that is running the browser hosting dashboards to be used for TTS announcements? I am frustrated with Google Home/Nest Mini speakers continuing to change my volume levels.
The system that is my main one runs Linux. Can the TTS be sent to the computer instead of or in addition to the Mini?
Vlc thing would work for this.
Please clarify. How exactly does one use VLC Thing?
Using an always on device like your Linux box you keep vlc running.
In hubitat you install the vlcthing driver and configure. It then can be used for notifications from any apps.
Since it is a SmartThings driver, are there any changes that need to be made, or does it work as it is? I hesitate to install something without knowing whether it could put my Hubitat system at risk.
I tried importing the code into a device driver and it failed.
I've written code that does what you want - Linux and OSX but it uses MQTT to communicate
with a new HE driver -- kind of a heavy lift to install it all if you're not a programmer. It can also function as a Chime and a Siren.
I'm not a programmer, so that might or might not be something I could tackle. I can follow a set of instructions to do so, but I'm not sure if installing the code would be that straight forward. I have not experience with MQTT.
One requirement I had was that it had to be available after reboot on the Linux machine. That means a systemd launch script which needs editing per site. Obviously, the Linux system has to be running when Hubitat needs to talk. Fortunately, it's harmless code if it's not setup correctly and mosquitto for mqtt is simple to install on you linux system. The Readme is slightly out of date but it gives you a good idea for what skills and tasks are needed
Okay. I'm looking at it. I might be able to handle it. It will probably be a bit before I start on it. I want to make sure I understand it before making any changes on my Linux system or on the Hubitat hubs.
I tried this solution tonight on my Arch Linux system. I have MQTT broker running from the Mosquitto package. The connection is always getting refused though by my machine.
dev:1812021-03-07 08:34:07.562 pm warnTTS Via MQTT : Unable to connect to server (32103) - java.net.ConnectException: Connection refused (Connection refused)
dev:1812021-03-07 08:34:07.558 pm warnTTS Via MQTT : Error when trying to connect to 192.168.1.170:1883
I was able to get this to connect though to my Android running a broker as a test, with no issues. (obviously no Hubitat python things which are in your GitHub) My Linux box does not have any internal port blocking and it should be able to communicate with no issues. I have verified that Port 1833 is being listened to with the netstat command:
netstat -anp |grep 1883
tcp 0 0 127.0.0.1:1883 0.0.0.0:* LISTEN 7178/mosquitto
tcp 0 0 127.0.0.1:35907 127.0.0.1:1883 ESTABLISHED 22451/python3
tcp 0 0 127.0.0.1:1883 127.0.0.1:35907 ESTABLISHED 7178/mosquitto
tcp 0 0 127.0.0.1:1883 127.0.0.1:60562 TIME_WAIT -
tcp6 0 0 ::1:1883 :::* LISTEN 7178/mosquitto
Do you have any ideas by chance on this?
First guess would be authentication. In particular, I don't use any on my broker (mosquito) so if yours does need name and password that has not been tested in my groovy code. Should be a simple fix if that is the problem. There are logs for mosquito if you know where to look and interpret. That would help figure out what the problem is.
I fixed the connection, it was using a local connection only, I had to allow external with
listener 1883
allow_anonymous true
I have no sound though my speakers on the MQTT Device (*My Desktop) - but I can play the sound in the URL the log gives out. My system is using PulseAudio as well.
After the "Sending MQTT:.." part, is there a return code or does the log stop there?
Any Ideas on the reason for no sound?
I should look at the code but I'd bet it copies the clip to local disk and then shells to 'music' player to play then file. Which player and do you have it in the path is the important info to know. For testing, you don't have to run the linux code as a systemd process. Fire up a terminal, cd to where the python code is and launch from the terminal. The python code for playing is not complicated and right at the top of the file.
Now that I look at the code, it should be logging plenty of info about what it's doing. If its a daemon then tail -f /var/log/syslog. If you launched with a $ python3 alarm.py -c your.json it should display some progress messages. It's looking for the program 'mpg123' - you may have to install that program. $apt install mpg123
I forgot that I complexified that code.
My mpg123 is here:
/usr/bin/mpg123
I ran the command you suggested on the command line and it is giving the following information: (For initial playing around and testing, I used your default examples in the Github link)
python3 alarm.py -c bronco.json
04:46:44 INFO Settings from bronco.json
04:46:44 DEBUG Homie_MQTT __init__
04:46:44 DEBUG Begin topic creation
04:46:44 DEBUG homie topics created
04:46:44 DEBUG Init() Subscribed to homie/bronco_play/player/url/set
04:46:44 DEBUG Init() Subscribed to homie/bronco_play/chime/state/set
04:46:44 DEBUG Init() Subscribed to homie/bronco_play/siren/state/set
04:46:44 DEBUG Init() Subscribed to homie/bronco_play/strobe/state/set
04:46:44 DEBUG Init() Subscribed to homie/bronco_play/player/volume/set
04:46:44 DEBUG Init() Subscribed to homie/bronco_play/chime/volume/set
04:46:44 DEBUG Init() Subscribed to homie/bronco_play/siren/volume/set
04:46:44 INFO ==== Settings ====
04:46:44 INFO {"mqtt_server_ip": "127.0.0.1", "mqtt_port": 1883, "mqtt_client_name": "bronco_play", "homie_device": "bronco_play", "homie_name": "Bronco Mp3 Play"}
It stops right after that and doesn't exit or proceed beyond that line unless you issue a Ctrl-C command.
That server ip number only works if your mosquito broker is on the same machine as the python code.
That waiting is normal until Hubitat sends something to those mqtt topics. Make sure Hubitat is setup with the same name 'bronco_play'. Also ensure you are using the Mqtt TTS driver:
The README says to use the mqtt alarm driver in Hubitat. Outdated! Use the 'Mqtt TTS` driver
You have a differnet looking version of the device settings from what I have. My Screenshot is below:
I don't have the same set of voices as you have and you can see the verbiage is different as well. Unless that is your Dev version. 
For what it's worth, I grabbed the driver code from here: Hubitat-Drivers/TTS to MQTT Driver at master · mhutchy/Hubitat-Drivers · GitHub
That could be a problem!?! That is not my code. Mine is here My python code is here. The log entries you showed looks like my code so you might be good there, Please update the hubitat code - mine in not in HSM you have to do the manual cut/paste.
Yup! I was using the wrong code, I now have the same GUI as yours, but I'm stiil not getting sound. Latest entry in the log:
dev:1812021-03-11 08:42:34.499 am debugspeak(hello) => http://192.168.1.14/tts/9271ecdc192639d412d6875538b94dd9.mp3
dev:1812021-03-11 08:42:34.488 am debugtemporary setting tts volume to 30.
dev:1812021-03-11 08:42:34.483 am debugusing tts state.tempVol 30
I know it's doing the right thing there, and I confirmed the alarm.py is correct.
I'll try to locate the mosquitto log. Arch doesn't use a standard logging system, instead pushes out to the journal.
Fix your bronco.json to use 192.168.1.14 - same ip # for hubitat and python.
Edit:
The logs from alarm.py should be enough. It will tell you that 'something' publish on the bronco_play (sub)topic. Assuming its a tts command or chime or than it will inform you of that two. It's very chatty. don't use the '-d 2' flag.
Download the Hubitat app
