[REQUEST] When: Input changed

[powermarcel10]

Hi!

I'm comming from the Marantz app, and there is a trigger card that triggers when the input of the receiver changes. Is this something you can implent?

Here you can see wich cards are availible with the Marantz app:

https://homey.app/nl-nl/app/nl.marcovandenhout.marantz/Marantz/

Cheers and thanks, Marcel

[murderbeard]

Hi Marcel,

Working on this at the moment. I'm wondering what kind of trigger card you're looking for. In the test version currently there's a single trigger card that has a token on it, which is the response from the receiver.

So whenever the source changes this card is triggered and the string token might be MPLAY (for mediaplayer), DVD, BD (for bluray), AUX1, etc. This differs from the actions card to select the source, which is a dropdown menu with the full source names. However there's already the condition card to check if a channel is active, which also uses the dropdown menu.

So I'm wondering if just having the trigger card (with short string version of the source name as a token) covers most people's needs or that the trigger card itself needs a dropdown. Or have two versions of the card, one for people that want the string response itself and one where you can select the source from a dropdown (so channel changed to AUX1).

In what way would you use the trigger card, and the tokens or conditions it?

Best regards and thanks, Ralph

[powermarcel10]

Hi Ralph,

Thanks for making some time for this!

Personally I don't think it makes a lot of difference.. I think a dropdown menu in the trigger is the easiest way to configure flows, but the other way is also fine.

If I have to choose, than I prefer the dropdown menu, but like I said, no big deal if you do it the other way.

I will test the testversion tomorrow!

Thanks again.

Cheers, Marcel

[murderbeard]

Hi Marcel,

It'll take some more time to push out a test version. Receivers with multiple-zones send out multiple messages which can get mixed up. So the app might think for a short while that the main zone switched to whatever the second zone is set to. After which it's set back to what is actually is in the next update. I've fixed this in my version where it will only process the first message. But sometimes the two zone messages get combined together, which I still need to fix. So I'm currently getting regular source change updates that make no sense.

Similarly this made a bug clear where a (secondary) message comes in that is related to getting the volume level. And it mistakenly taking MV450 as the input source for example. So this'll need to be addressed as well before sending out a version.

Cheers, Ralph

[murderbeard]

This is still in the works. Now works reliably on my receiver. I'm thinking the update will come after the release of the new homey pro 2023.

[mouali92]

Hey there Ralph,

I'm really, extremely, looking forward to this feature :) Any news/idea on when it might be live? I'll be using this feature to control the lighting en shades in my living room based on the chosen input :)

Cheers, Mo

[murderbeard]

Hi Mo,

It's long overdue to bring this update out. The current test version only has a flow card which returns the current channel as a string token, which works well but I'm thinking of adding another card with a dropdown list with the same options as the switch channel action flow cards. But as that list isn't exhaustive, with different models having different sources, the other flow card should also be available. But I think it's easiest for people to have a dropdown list. (A whole other can of worms is that people can actually change the source's name in the receiver, which shows up on the receiver's display, but in the background the name is still the old one. In my case I've renamed the MEDIAPLAYER source to be PS4, but to set it via Homey I still have to use MEDIAPLAYER. I've yet to hear any requests on that though.)

As stated above this update brought to light some issues which seem to be fixed and stable at my end. I'm thinking of publishing this first as a beta and send it out to people like you for a short test period. At any rate I want to publish something within the following days.

Cheers, Ralph

[mouali92]

Hey Ralph,

Thank you for your update! It being a string is definitely not an issue for me. I mostly work with strings already :)

But yeah I agree that the nicest solution would be where you have a dropdown with the given names, but on the other hand these names also do not match with the names that are printed on the physical remote control of the receiver.

Question: do the strings exactly match with what is on the remote? If so, then that would be the easy way to explain the users how they could use this card and the strings.

I would be happy to test it out for you. So please do let me know when I can install the beta version. And thanks for your effort and time spend on this! :)

Cheers, Mo

[murderbeard]

Hi Mo,

Thanks for the info! In regards to your question: the strings do not match up with the names on the remote. I think the texts that the user sees in the dropdown do match with the remote generally speaking. But mediaplayer becomes MPLAY for example, though I do think Game becomes GAME so that's the same except for the capitalization.

Below are the built-in values for the homey app and the names they translate to.

"id": "TUNER", "label": { "en": "Tuner" } } "id": "DVD", "label": { "en": "DVD" } }, "id": "BD", "label": { "en": "Blu-ray" } }, "id": "TV", "label": { "en": "TV Audio" } }, "id": "SAT/CBL", "label": { "en": "CBL/SAT" } }, "id": "MPLAY", "label": { "en": "Media Player" } }, "id": "GAME", "label": { "en": "Game" } }, "id": "AUX1", "label": { "en": "Aux 1" } }, "id": "AUX2", "label": { "en": "Aux 2" } }, "id": "NET", "label": { "en": "Network" } }, "id": "PANDORA", "label": { "en": "Pandora (US Only)" } }, "id": "SIRIUSXM", "label": { "en": "Siriusxm (US Only)" } }, "id": "SPOTIFY", "label": { "en": "Spotify" } }, "id": "FLICKR", "label": { "en": "Flickr" } }, "id": "FAVORITES", "label": { "en": "Favorites" } }, "id": "IRADIO", "label": { "en": "Internet Radio" } }, "id": "SERVER", "label": { "en": "Server" } }, "id": "USB/IPOD", "label": { "en": "USB/iPod" } }, "id": "USB", "label": { "en": "USB (Start Playback)" } }, "id": "IPD", "label": { "en": "iPod Direct (Start Playback)" } }, "id": "IRP", "label": { "en": "Internet Radio (Start Playback)" } }, "id": "AUXA", "label": { "en": "Portable In (N8 Only)" } }, "id": "AUXB", "label": { "en": "N5:Analog In / N8:Analog In1" } }, "id": "AUXC", "label": { "en": "Analog In2 (N8 Only)" } }, "id": "AUXD", "label": { "en": "Digital In" }

I noticed you're using a LG TV(?) together with a Denon receiver, if I'm not mistaken. For my set-up I use the WebOS homey app to determine which app is being used on the TV and set volume accordingly. For example I hate the autoplay stuff from Netflix so I automatically set the Denon to MUTE whenever that app becomes active. Also when I switch to the 'Denon app' (which is the HDMI input to the TV from the receiver) on the TV I automatically switch the receiver to the Game HDMI input. Most of the time the receiver is simply automatically set to TV Audio by the TV.

I was wondering, if you're okay with it, to share more of your set-up to see how you're using the app in combination with the TV. Sending it via a private message or email would also be fine by me.

I've finished up the work for the extra flow card and it seems to work fine. Will see if I can publish a beta version maybe today.

Best regards, Ralph

[mouali92]

Hi there Ralph,

Aah if only things would be logic 😄

You saw that correctly :) I have an LG G2 WebOS tv and a Denon X2700h. Currently I have all my peripherals connected to the receiver. I use an Apple TV as the platform for all my apps so I don't really use the built in apps on the tv. I'd rather connect all the peripherals directly to the TV but the G2 does not support DTS passthrough over HDMI ARC to the receiver. Even though I only use DTS for a playstation and blu-ray player I prefer to control all devices via one device, so in this case the receiver.

I'm happy to share some info on how I use my setup and how I've configured it so please do let me know if you've got any other questions :)

Can't wait for the beta version. I'll definitely let you know what my experience will be and I'll also share a screenshot of the flow where I'll be using it it.

Cheers, Mo

[murderbeard]

Hi Mo,

Thanks again. The test version is live here for anyone to test out. Please let me know how it goes.

BR, Ralph

[mouali92]

Thank you, thank you, thank you!! It works perfectly! And the dropdown menu is indeed the easiest solution.

Haven't noticed anything weird. It works exactly as expected.

[mouali92]

What I forgot was that when the receiver is off and is being turned on to a source on which it already was, then the source doesn't change. For that reason I've made this flow:

[mouali92]

Hii Ralph, @murderbeard

I've found a bug. When I change the input, the corresponding trigger cards do work. But the "AND" cards do not. So as you can see in the flow above. When I have te receiver on input "Media Player", the AND card does not register this as true. This is also the case for the other "AND" cards with "Blu-ray" for example. When I change the input, the flow does register this, but this is because those are the "WHEN" cards.

[murderbeard]

Hi @mouali92,

Thanks for testing it out. I think your idea to use the AND cards like that is the best solution - for my use case it wouldn't be helpful if the trigger cards are also triggered when the device gets turned on. But I'll investigate a bit more if that behaviour would be expected thing to happen.

The AND card is older than this new system so it doesn't use the info from the regular updates, it instead sends a SI? command to the receiver and reads its response. (So basically if you add another 20 of those to check what source is active then it might take like 10 seconds for it to reach the last when card).

What I think might be happening is that during the startup of the receiver there are more messages being received than that old when card expects. This has been fixed for the other cards but that one specifically doesn't filter out unexpected messages.

Could you try adding a delay (of 5 seconds or so) between the turned-on card and the (first) AND channel active card?

A fix might be to either: add the filtering option but keep the SI? command (keep the behaviour exactly as it has been for the last 5 years) or remove that altogether and just compare it to the last known source from the polling update (which makes the AND card resolve instantly, so it's faster, but it might be out of date by a few seconds, and somewhere someone's flow might be reacting a bit differently than expected).

Cheers, Ralph

[mouali92]

Hii Ralph,

Check! Then I will keep using the AND cards. This seems to be the standard, also with other apps :)

Unfortunately your tip dit not solve the issue. I've even put in a delay of 10 secondes. But I know for sure that the delay won't solve it because when I test this flow even after when the receiver has been on for an hour it does not output the blue flow line when it should.

If I'm correct then it would be a risk to use the last known source I'm not sure though. But do you know what would happen if I would shut down the receiver while on Media Player and would turn it on the next day by pressing the blu-ray button on the remote?

Cheers, Mo

[murderbeard]

Hi @mouali92,

Good catch, thanks for noticing. For this update the app reads 'ALL' information it receives from the receiver before closing the connection. Which in case of the AND card means it can also receive info on the second or third zone. So in my testing I received SIBD and SVOFF, which combined means absolutely nothing as a source. So now this card also filters the messages, like I was planning to, but glad you picked up on this before I published it.

There should be a new version online now v1.3.1 (https://homey.app/a/com.moz.denon/test/). Seems to be working fine on my end. The behaviour is still the same though, so for each AND card it does a request to the receiver.

By the way I've never in my life turned on the receiver by pressing a source button on the remote. It does indeed seem to immediately open the correct source without displaying the old one first.

Cheers, Ralph

[mouali92]

Hii @murderbeard,

After testing for a day all seems to be working perfectly 😃.

Thank you so much for the quick support :)

Cheers, Mo

[powermarcel10]

Hi and thanks for the progress.

Im having some issues with the app now.

When a flow is trying to turn on the receiver while it is allready on the app does not respond anymore. After I restart the app it is working again. Here is a diagnostic report: BC30120B.

[murderbeard]

Hi Marcel,

That sounds bad. Will check it out. The diagnostic reports are for athom employees only I think, so I'm not able to look up your report.

Could you specify the specific order of cards used. Is it simply the turn on card? I'll give it a try on my end to see if I can find out why it happens. And this is happens on the test version right?

Cheers, Ralph

[powermarcel10]

Aaaah I thought it was for app developers too.

Strange thing is that there are 2 actions for turning the device on. Can you explain why this is? For this case it doesnt matter as both options give the same result.

Flow:

When "X" than turn on device. Nothing special. As soon as I run the flow the app does not respond anymore.

[murderbeard]

The duplicate cards (including on/off and volume) is because of backwards compatibility. Back when the first homey came out the devices didn't have 'capabilities' like they do now, with the ability to control them in the app/dashboard, everything was done with flow cards. So when capabilities got introduced I left the old cards in to not break the flows of people. This however means we have duplicate cards now (for several years already) which is annoying. I do intend to deprecate the old cards so they can't be added to new flows but they remain working for existing flows.

[murderbeard]

@powermarcel10 good catch. Somewhere in the upgrade of the test version the on/off capability got messed up. It made a 'read request' to the receiver instead of a simple 'send and forget', which never returned anything so it got stuck waiting. New version coming. Plus a fix for the connect timeout not firing, sometimes making the app wait the full 30 seconds or before it considers the connection a failure.

[murderbeard]

New version live at https://homey.app/a/com.moz.denon/test/