Volume control problem

[szappanyos]

For some devices it would be better to be able to send SEND_START and SEND_STOP using the web API because sending a single SEND_ONCE changes very little in volume. If I have time to do it I will fork the project and open up a pull request.

[paulgration]

I've been working on something similar and have implemented send_start on button press and send_stop on button release from a web UI - works fine so far and more closely matches the use of a real remote control though I have so far done minimal testing. There may be scenarios when only sending the signal once / a specific number of times is required so I've provided API's for both e.g. /api/irsend/send_once remote code repeat (optional) /api/irsend/send_start remote code /api/irsend/send_stop remote code

These are POST requests in mine so the data fields would be the lines beneath the API endpoints.

At some stage I plan to introduce a feature to 'edit' a remote control whereby the user could change the behavior of the buttons to call the different APIs.

Just thought I'd share as Alex's project and mine (which won't be completed for a while yet) share quite a lot of similarities so this may be useful.

[alexbain]

Ah, that's an interesting point you bring up. I fear that changing the behavior of the buttons globally would introduce bugs where 'holding down' the power button would cause a device to flick on/off rapidly. @pmgration - have you experienced that with your system? I'm thinking it might make sense to introduce this as an option for certain classes of buttons - volume controls, channel controls, etc.

Do either of you have any thoughts on how this behavior might be implemented conditionally? Perhaps trying to match against the button name (vol, volume, etc), or adding some sort of metadata within the LIRC config?

[joe-forbes]

Sorry if I'm butting in, but if I'm not mistaken, telling the difference between rapid pressing of a single button and repeated sends while the button is being held down is the function of the toggle bit in the RC-5 and RC-6 protocols (and possibly others). I suspect that if the toggle bit is defined for a remote, that it should be safe to use send_start and send_stop for all commands for that remote.

On Tue, Dec 17, 2013 at 10:36 PM, Alex Bain notifications@github.comwrote:

Ah, that's an interesting point you bring up. I fear that changing the behavior of the buttons globally would introduce bugs where 'holding down' the power button would cause a device to flick on/off rapidly. @pmgrationhttps://github.com/pmgration- have you experienced that with your system? I'm thinking it might make sense to introduce this as an option for certain classes of buttons - volume controls, channel controls, etc.

Do either of you have any thoughts on how this behavior might be implemented conditionally? Perhaps trying to match against the button name (vol, volume, etc), or adding some sort of metadata within the LIRC config?

— Reply to this email directly or view it on GitHubhttps://github.com/alexbain/lirc_web/issues/3#issuecomment-30816310 .

[alexbain]

@joe-forbes Ah! Perfect. In that case, I'll experiment with swapping out the click handler with mousedown/touchstart and mouseup/touchend events and see how that behaves with the devices I have programmed in LIRC. If everything behaves predictably I'd be down to swap the functionality.

[paulgration]

As @joe-forbes mentioned if the toggle bit is in place it should behave correctly and in theory be much closer to the use of the real remote control. I have a Samsung TV that requires only one signal transmission to power off, but around 4 to power on so would have to use the repeat functionality of irsend for this, or the send_start / send_stop. I've only done some minimal testing with send_start / send_stop and with one device so far but it has worked as expected. The only issues I see are with potential network delay should some network related problem occur between the start and stop API calls being received, or if the stop doesn't get received at all for any reason - then you'd end up repeating and possibly confuse the device you're controlling but I think these scenarios are quite unlikely. One further thing to think about, which I haven't gone into yet (as I'm still working on the backend) is front end control and managing these API calls. Mousedown and mouseup should work (that's all I've implemented so far for testing) though I haven't tested browser behaviour for example if you were to mousedown, then mouseout and mouseup (which I imagine as the mouseup hasn't occurred on the element, it wouldn't trigger the stop call) - just something to think about. And there's keyboard interaction of the buttons too if you wanted to cater for these. Regarding the editing of remotes, although send_start / send_stop more closely matches the behaviour of interaction with a real remote control I can see there may, in rare cases be a desire to ensure the signal is transmitted only once, or a specific (precise) number of times so it might be nice to allow for users to configure the actions of the button. Again I haven't looked into exactly how this might work yet but would probably aim to do this outside of LIRC. Although keeping the data in one place is almost always the best option, I'd prefer not to customise LIRC configurations..

[szappanyos]

I was thinking to introduce some parameters for a single key. For example /remotes/remoteX/volup/5 where 5 is to send the key 5 times. This would be useful when only 1 key press would change very little in volume. I am using the project with Tasker and Pebble Watch. The goal for me would be to change the volume with the watch the following way. When I press and hold a button send a send_start and when I release the button to send a send_stop to the lirc_web api. I have to check the Pebble SDK also if it would support something like this and Tasker also. For now the simple way is to specify to send a key for 5 times for example.

I'll get back if I made some progress in this regard.

[paulgration]

Let us know how you get on @zoli7, I guess you need to add support for the count (-#) switch of irsend in lirc_node and make a call to it in lirc_web. This is what I did with my project - I should probably publish at least the API for mine at some point, it would be useful to get feedback from lirc_web users like yourself, Joe and Alex.

[alexbain]

@pmgration - Yeah, please do publish whatever you're comfortable open sourcing. It would be great to collaborate and share some code between projects.

[alexbain]

@zoli7 I went ahead and implemented this, and rolled it up with a bunch of other changes which I tagged v0.0.7 and just pushed to master.

Here's the pull request with the work, and the thoughts behind it:

https://github.com/alexbain/lirc_web/pull/5

[alexbain]

Going to close this, since it's implemented. Thanks for the suggestion!