I just installed openHAB on Ubuntu Studio 22.10 and was adding stuff I have.
I began with THINGS vesync (Levoit Humidifier 300s) then hue lights.
I also have ROKU and Denon receiver working at the equipment page.
The Shield TV P3430 in installed but I don’t see it (yet) on the server home page equipment.
Is there somewhere I need to edit local files or should it appear in THINGS ?
First make sure you’ve gone and installed the shieldtclv 3.4.0 binding from the marketplace. Once that’s in, auto discovery should find the shield when it sends its periodic broadcast (which isn’t frequent, especially if it’s off). If that doesn’t happen, try to scan for it. That will usually force it to discover. To note, discovery only works if the openhab and shield are on the same network/vlan.
Looking for some input from the users. I had some time yesterday to begin working on the app pieces. It looks like we get 3 pieces of info. An app DN (e.g. org.google.youtube.tv), a real name (e.g. YouTube TV), and a URL that pointals at the shield for the app. The URL has yet to be explored by me but I believe it may provide at a minimum the icon for the app, possibly some app control (perhaps if the app has its own API?). I’m planning on adding an appname and appurl channel so that when the app reported matches something we know, we get the additional data.
The question I have for the users. Im considering another channel along the lines of appdb. Basically this would be a parasble (json maybe?) dump of what we get from the shield. I figure at a minimum it would help users figure out what they need to send to the shield to start an app. Beyond that, it may be helpful in rules or something similar. Is this channel worth the time to code? The alternate would be to just dump it to debug logging and let people grab as needed for one-off reviews.
Thoughts?
Also to note, I’ll be modifying this post to be 4.0.0 beta, and creating a 4.0.0 stable post for those who want to be more in line with what is being submitted to merge. I’ll also likely create a 3.4.0 beta as well.
While I haven’t thought this through at all, what about adding the apps you find to a dynamic state/command description on the existing app channel? It could serve multiple purposes, not the least of which would make it easy to launch an app by selecting it from a list.
Interesting. Ive never done that, but I’m up for learning. Are you suggesting to just do that or do both that and the channels for those who just want an easy item to display?
If I understand correctly (and please correct me if I’m wrong), but
To launch an app, you send the DN to the app channel
If there wasn’t a bug in the Shield, the app channel would be updated whenever an app gets focus on the Shield. Currently, the app channel gets updated after you send a keypress.
The app DN and real name would be set as state options in the dynamic state description. UIs (Habpanel, Basic UI, etc) could then present a selection list to the user for the item(s) linked to the app channel.
In addition, you can access all the state options in a rule by iterating over the list. In DSL, it looks like this (for the SqueezeBox binding’s favorites list). In the case of the Shield, option.getValue would be the DN and option.getLabel would be the real name. That would provide the means for someone to learn the DN and real name.
Take a look at the vizio binding… There is a JSON database that maintains the list of apps and the metadata needed to launch them. It is editable by the user in the thing configuration. By using this information, the binding can show a drop-down channel of available apps and upon selecting an item, the desired app is launched. Likewise if an app in the list is started via the TV remote, the channel updates to show the currently running app.
To clarify this, the bug only happens before the first keypress from what I’ve experienced. Once any keypress is made, the bug is gone for the duration of the connection.
We get the app list basically as soon as login happens. Would this still work since it is generated so quickly?
Yes. It comes in as one big blob about 5 payloads after login is completed. I can actually call for it as well if needed for a refresh (which I should probably do periodically, haven’t gotten there yet).
Ok, so when you get the blob, you use it to populate the state/command options. There are many examples in bindings that show how to do dynamic state or command options.
Sounds fun. I’m close to getting the decoder done (6 hours later). This protocol is such a mess. 98% of the time the app has a prefix that is 5 bytes long. On some rare occasions, it’s 6 and it’s really hard to figure out when that is. Also apparently some apps can have multiple entries. Plex seems to actually be an offender of both a 6 byte prefix AND multiple apps so figuring out how to catch that has been, trying on my patience lol.
That is correct. The approach of saving the list as a persistent configuration option was used because there was no way to query for a current list of installed apps on the TV.
Just to give everyone a real world of what I’m talking about. I believe I finally have the decoder working. Working here means “my two shields aren’t throwing errors anymore and are parsing correctly”. Here is what I get (below). I’m not sure why a few like hbo and espn are missing the first 2 bytes of data (3001 in most cases) other than something the plex app is doing. I do believe that the data between the two 0x0a is the overall length of the entry, with the only thing that it’s got an endian issue (e.g. disney being 30010a89010a means the length is 0x0189 where youtube tv being 30010a650a means the length is 0x65). I ended up not actually needing that to parse it because it has other delimiters and length fields which were easier to work with.
Thinking out loud… I wonder if it would be worth wrapping the code with try/catch for ArrayIndexOutOfBoundsException. That would give you the chance to log some relevant information to help with debugging. Mostly thinking about if a problem occurs in a user’s environment. Probably a question that should be answered as part of the review of the PR.
Honestly, that entire function should probably be in a try/catch now that you’re mentioning it, not just the individual message.
That said, I don’t think that I should be able to hit an out of bounds the way this protocol works. While it’s a pain, it is somewhat deterministic once you figure out the delimiters. The end of the packet will always be 5 bytes long after the last entry. Also, from a debug standpoint, the best thing (for me) if someone has a shield that freaks out is to get them to run trace logging and to get the actual payload from them. There is a hidden raw message decoder channel that I can send their payload to on my side which fakes a packet receipt and processes it. In theory, it should barf in the same places as long as the payload is the same.
I’m not even going to call this a beta or release it as such. I’d like a few people to give this a try to see if it throws any exceptions (I think I’ve got them all caught). There are several apps (like the default launcher) which aren’t sent as part of the payload and had to get loaded manually. I’ll drop a cleaner version once I get the kinks worked out.
Two new channels are appname and appurl. They should auto populate as app changes.
Watch the log file for errors that say “Unknown Android App” at the info level. If it spits one out, please send me the DN so I can find and add it to the default load.
EDIT: Standby for a 3.4.0 cut of that, should be later tonight or early tomorrow.
To note, I still intend to do the dynamic channel part. Trying to make sure the decoder is working properly first. Once I know its “cleanish” I’ll add the dynamic channel and drop it as a beta.