Sorry for being a bug on this one. I truly appreciate your assistance. I have the following directory structure:
ls -la
total 96
drwxr-xr-x 6 root root 4096 Mar 10 20:38 .
drwxr-xr-x 4 root root 4096 Mar 7 18:16 ..
-rwxr-xr-x 1 root root 6949 Mar 11 09:45 alarm.py
-rw-r--r-- 1 root root 1013 Mar 7 18:16 alarm.txt
-rw-r--r-- 1 root root 162 Mar 11 09:56 bronco.json
drwxr-xr-x 2 root root 4096 Mar 7 18:16 chimes
drwxr-xr-x 8 root root 4096 Mar 7 18:16 .git
-rw-r--r-- 1 root root 184 Mar 7 18:25 hubitat-alarm.service
-rw-r--r-- 1 root root 644 Mar 7 18:16 iot-alarm.plist
-rwxr-xr-x 1 root root 155 Mar 7 18:16 iot-alarm.sh
drwxr-xr-x 3 root root 4096 Mar 7 18:20 lib
-rwxr-xr-x 1 root root 473 Mar 7 18:16 mac-update.sh
-rw-r--r-- 1 root root 161 Mar 7 18:19 mini.json
-rw-r--r-- 1 root root 184 Mar 7 18:23 MQTT
-rw-r--r-- 1 root root 201 Mar 7 18:16 mqttalarm.service
-rwxr-xr-x 1 root root 95 Mar 7 18:56 mqtt-alarm.sh
-rw-r--r-- 1 root root 9143 Mar 7 18:16 README.md
-rwxr-xr-x 1 root root 304 Mar 7 18:16 rpi-update.sh
drwxr-xr-x 2 root root 4096 Mar 7 18:16 sirens
-rw-r--r-- 1 root root 163 Mar 7 18:38 trumpy.json
-rwxr-xr-x 1 root root 307 Mar 7 18:16 update.sh
I edited the bronco.json to have the Hubitat's IP. For the rest of your statment about Same IP# for Hubitat and Python.... are you referring to specific files?
Also, are logs from alarm.py stored somewhere that I am not seeing? (as in this directory I shared)?
Sorry for the confusion. Hubitat and the python code (aka the ,json file) have to use the same IP number for the MQTT broker, earlier you had 127.0.0.1 has the broker address which only works if the box with the sound output (python code) is the same as the mqtt broker. A very useful debugging tool for mqtt is MQTT Explorer, you'll have to search for it. It's comes in a nice appimage for Linux so it's easy to run. Just point it to your broker and you can examines the payloads and topics.
The process is pretty simple. My Hubitat driver has hubitat (and amazon) convert the text to an mp3 file on the hubitat box. It sends the url of that file to the mqtt broker and 'topic' The broker wakes up the python program listening for activity on that topic. The python code downloads the mp3 from the hub using the url -> creating a tmp file on the linux box and spawns mpg123 to play the tmp file.
Because the MQTT topics are 'homie' compatible my hubitat driver builds the final topic string from 'bronco_play', in this case. You'll see it with Mqtt Explorer.
I have the MQTT explorer and have found the topics there. To give you a rundown -
My computer that I am running this on, has the speakers and is 192.168.1.170 - Hubitat is 192.168.1.14. For the json file, I told it to look at the local host 127.0.0.1 in this case.
I guess my broker in this case is not waking up the python code. This is the output from the MQTT explorer to show it is getting the broadcast at least:
Good - half is working correctly. I think your diagnosis is correct. The mqtt broker topics look good. and you can see the url of the tts mp3 file in the homie/hubitatalert/player/url/set topic. I don't like the 127.0.0.1 topic line in your Mqtt display, but it's not likely to be the problem. Just a confuser. We need to get the json file set up to match.
I changed the json to that and I still have no output.
From the command line though, I was able to play the file with the mpg123 command line pointing to the Hubitat url it created in the log.
It feels to me like the script is not activating the mpg123 program itself.
mpg123 is located in the /usr/bin/ folder. I checked the alarm.py file and do not see it mapping there, but if I am wrong, is there a different file I could check by chance?
It should find it in /usr/bin - the suspicious code is at alarm.py:38 and looks like player_obj = Popen('exec ' + cmd, shell=True)
Presumably, the shell=True would have /usr/bin in the shell's path but I suppose that doesn't have to be true. You could edit lib/Audio.py:40 so it looks like self.play_mp3_cmd = '/usr/bin/mpg123 -q --no-control'
Edit: My mpg123 is in the same place (Mint 19.3)
ccoupe@bronco:~/Projects/iot/alarm$ which mpg123
/usr/bin/mpg123
ccoupe@bronco:/usr/local/lib/mqttalarm$ ls
alarm.py chimes mqttalarm.service sirens
bronco.json lib mqtt-alarm.sh update.sh
I made the changes you suggested in the Audio.py file and still not having any luck. I will keep an eye on the README for your changes after they've been made.
New README is up. Includes screen shots for Hubitat. I'm sure there are typos. I'm sure some things need re-phrasing and there is probably something missing.
Remember to Save Preferences if you change them on the Hubitat side. If you change the json file on the linux box, CTL-C and restart the python code to pickup the change.
I'm happy to hear that. Testing the systemd service files is a pita but its just directory paths to be fixed if it isn't working from a restart. Hopefully Arch didn't move syslog.
I have an interesting situation here. I finally got around to setting up a rule to alert me when the front door is open by TTS. There are a couple of things, sometimes it works and other times it doesn't. When I test it through the driver for the TTS to MQTT, it sometimes fires and other times not. Logs indicate no issues in the Hubitat logs. In the next month or so, I will be outfitting a Raspberry Pi for this purpose once I get some good speakers.
The groovy driver is pretty simple - a clean path from Amazon to the mqtt broker. Unless Amazon is not responding - I have seen that a few times. I've also seen cases where the other end - the linux system didn't boot with pulseaudio in the proper state. That's a lot harder to debug and to fix. The Linux side log (syslog) should show something useful. Hubitat needs amazon for the TTS so it's totally local only.
Beware that the 3.5mm audio jack on raspberry pi is, uh, piece of crap. Maybe you'll get lucky, maybe you won't. Bluetooth works OK as does the HDMI if you have a way to get the HDMI audio. USB audio dongle to 3.5mm also work and cheap. If DAC quality is an issue you care about then you'll have to be careful.
