Hello Sofabaton Just to advise this specific issue fixed with hub FW6 Thank you David and Sofabaton team. The other input issue still remains. But things are looking good.

Hi there This one been logged here.. The first part of that which is to do with sequences that chop and change between long press and short press has been fixed already as if 16th. (This was why my test at device level and test at activity level didn't work) The second and main part which is what you're referring to is exactly same issue. http://bbs.sofabaton.com:8091/post/1945 David in support is working slowing with me through that issue and I'm confident we have the same root cause. Actually what I see is more extreme, If we have anything except the default command already applied them it's ignored completely. Not even the first press. https://www.reddit.com/r/SofaBaton/s/LunP7kLPcJ There's what I think is a closely related issue for input switch too. If that's modified to one of the canned sequences that need more than one step that's also ignored completely. Again confirmed that boot even the first click is sent. Both easily confirmed by putting in bonkers test sequence. E.g. "eject" instead of say power or input controls. If even the one command fired then the eject button wouldn't been fired. http://bbs.sofabaton.com:8091/post/1947 https://www.reddit.com/r/SofaBaton/s/97kGtdCxqk

P.s. I've also seen devices give up and think you've stopped your sequence because Sofabaton is taking too long

This forces a sequence that in Harmony could execute in half a second total, but Sofabaton takes about three. For another sequence, Sofabaton takes 12 seconds where harmony would do it in 3

Confirmed It's annoying especially if a device only has discrete power off command and not discrete power on. The Sofabaton will send a repeat of the power-toggle command even when it doesn't need to. Harmony remembered which devices were on and which were if and only triggered the on or off events if the device was new or not needed for the next activity or power state

Agreed Input switching is also impacted in nearly identical way. If I've configured a device to one of the two indirect methods of switching inputs using a menu and then arrow key presses, or repeated press of the same input button then Sofabaton gets confused if the same device in both current and next activity. That happens even if the "when device starts" correctly to the top of the list, and "normally press" correctly to remember last input. The issue is that when switching the activity Sofabaton forgets the last input, but because device powered for both before and after it's actually remembered. Sofabaton then starts counting again from the top and mucks things up. Also there's something wrong with the starting from 0 position logic. I can't quite put by finger on it, but when directly testing inputs using the fix command, if the targeted input is above the current input, Sofabaton tries to go off the bottom but miscounted the 0 item (which is actually first in the list). I think they need to get rid of the zero, and think carefully about the remembered last state and start from top settings

Thanks. And good idea. I was wondering that would be a good place to put that.

summary, a bit like the custom activity power issue, the custom input selection has serious defects that both corrupts the detail of an input selection requirement, but also doesn't trigger even one click of the corrupted sequence at all.

P.s. when creating activity I do also add the input selection requirement to the activity. The other thing I notice is no matter how many times I do that, if i open the startup configuration on the activity, it always seems to default to "do not switch sources"

Hello Yes controller is fully upgraded I'll email screenshots of what I suspect might be the cause to the email thread that I have with you. In summary I don't think the input sequence is saved properly at all. I can configure Input And then (below is assuming your zero is actually position one, but I have tried also starting from 0) 1 2 3 4 5 6 7 8 9 0 And then weirdly you ask for a select command, which isn't actually needed when doing numerical affect. But whatever, for now while debugging let's put in "ok". (That's separate defect, requirement to select shouldn't be needed if doing numerical settings, that would be needed for your other two options of cursor up/down and then ok) I then name the inputs as above. Finally I tell Sofabaton that the player defaults to first setting when first letter on, butremembers last setting while powered. Needless to say it doesn't work. Not even the "input" button is pressed to bring up the menu. The activity switch isn't selected at all. But this is where I think the issue resides. If I now go in to configure the page it's lost the ones 0,1,2,3,4,5,6,7,8,9,0 entirely !