Forgot to answer your second question.
Your pull request retrieved the list of playlists and stored them as a state variable. This state variable was then used to populate an enum dropdown list in device preferences, which could be read by the updated() method and pushed to Volumio when the preferences are saved.
I have a couple of reasons that I did not keep this method.
- First, device state variables aren't visible to rule machine, so they're not exposed to be pulled into a rule. Likewise, rule machine can't change device preferences, so using a device preference to select the playlist isn't accessible to automations. I'm not sure if they are accessible to dashboards, but I suspect not.
- Second, device preferences should be for things that are changed infrequently (like the hostname) and not used for everyday operation of the device. When the updated() method is called by saving preferences, it also calls initialize(), which sets up scheduled actions and enrolls in push notifications. From a code efficiency standpoint, I don't want those to be called every time a user changes playlists.
- Third, I don't allow everyday users access to the Hubitat app to directly access device commands. They go through a dashboard that triggers rules or device commands, so a preference to change playlists wouldn't be usable unless device preferences can be exposed to dashboards somehow that I don't know about.
By putting the list of playlists in a device attribute and using a command to set the playlist, it exposes both of them for rule machine to grab and manipulate or for dashboard tiles to display and control. Additionally, for automations, the user would presumably be triggering a rule, not typing in a playlist name themselves. I agree that having a drop-down list in the command would be clean, but I was unable to get the command to pull an enum list from either a state variable or an attribute. This seems like a limitation on how Hubitat interprets drivers.
For your case, here's what I think happened:
State variables are persistent until they are explicitly cleared, even on a page refresh.
You still had a state variable set from the 1.04a "beta" driver.
Updating the driver to 1.05 changed the way the driver works, but did not clear the state variable, which still displayed the old information.
Renaming your playlists in 1.05 didn't change the state variable, leaving the state variable out of sync.
Removing and re-adding the device cleared the state variable, because Hubitat considers it a new device.
The state variable was never created again because the 1.05 driver doesn't do that.
AH, ok, thank you for the clarification!
I have everything working beautifully now, its quite nice, so thank you for making my life better, it is much appreciated! (no really, this has been a major life improvement)
I did want to ask about setting webradio or youtube playlists, as i have been playing with them and not been successful as of yet. In my web radio, saved under 'my web radio', i have a channel saved as "Scifi" but when i create the rule, it does not apply, so I feel like I am missing something obvious here;
It looks like your RM variable playtrack is passing only the string "SciFi.radio" to the playTrack command, and Volumio doesn't know what to do with this.
It should be the full uri for whatever radio station you want to play ("http://yp.shoutcast.com/sbin/tunein-station.m3u?id=1847449"). Also, playTrack requires the music service ("webradio") to be passed to it as a second variable. The Volumio API can't figure out the music service from only the uri, for some reason.
If you try it using the Play Track command in your device details page and it works, then it should work in rule machine using the same variables.
apologies, I am having difficulty in understanding the string I am expected to be passing along in playtrack. would you please give me an example value?
my sincere apologies for being dense.
Try it like this. (replace the uri with your own, obviously)
The variables correspond to the required inputs on the Play Track command. Title is optional and can be anything you want, or omitted completely - its only function is to display a descriptive name in the play queue.
how are you getting boolean type device in your variables?
also, how are you constructing your string value?
The %device% variable is automatically created by hubitat - not important for what we're doing. The only variables I created are %trackName% and %musicService%.
You don't need to construct a string in the rule. In the example above, I'm passing two separate parameters into the command. In your screenshot, set the string value to %trackName% then click "Done with parameter". Click "Add another parameter", type string, and give it the string value of %musicService%.
Edit: Forgot to put this screenshot in.
I feel so, ...INCREDIBLY, DENSE at the moment!
That got it working, my thanks for helping me through this, I do very greatly appreciate all of your help and PATIENCE with me, navigating this web interface with blinders on.
I was so hyper fixated on the formation of the string as a whole, that it never occurred to me to try adding them as separate entries!
We've all had those moments. Glad it's working now.