RS-2116Ex3 and toadtog

[jaylow48]

I recently installed a DishNetwork DVR-522. Since I can't find discrete codes for power on and off, I decided to try my luck at using toadtog in some of the macros I'm using to control my various devices.

My system is made up of the following components:

A Sony KV-32FS200 TV
A DishNetwork DVR-522
A Sony STR-K740P receiver
A Sony DVP-NS725P DVD player
Radio Shack 2116 w/extender 3

I'm setting up macros on device keys to configure each of these devices. I would like for the macro I use to control my DVD to turn the 522 off if it's on but leave it off if it's off. The macro to control the 522 would turn the 522 on if it's off or leave it on if it's on.

I've searched the forums and read everything about toadtog that I could find as well as reading everything that was included with extender 3. At this point, I'm unclear what's the purpose of the toggle 0 thru 7 and the condition (toggle, test only, force on, force off) are. I'm also unclear how toadtog keeps track of a device state, especially after the remote is reset.

In an attempt to get something working, I setup the following 3 keymoves:

SAT phantom1
Device type: MISC
Setup code: 1800 Protocol: ToadTog
Toggle: 1
Condition: Test Only
Buttons for On: Power
Buttons for Off: blank

SAT phantom2
Device type: MISC
Setup code: 1800 Protocol: ToadTog
Toggle: 2
Condition: Test Only
Buttons for On: blank
Buttons for Off: Power

SAT phantom3
Device type: MISC
Setup code: 1800 Protocol: ToadTog
Toggle: 3
Condition: Toggle
Buttons for On: phantom1
Buttons for Off: phantom2

I've also set up the following macro to test:

Bound key: SAT
Macro keys: DEV_SAT; phantom3

The macro doesn't work as anticipated because it takes 2 executions to change the state. I'm not sure if this approach is correct and, if it is, how to incorporate it into the macros I described above.

Any help would be greatly appreciated.

jaylow48

[johnsfine]

At this point, I'm unclear what's the purpose of the toggle 0 thru 7

To have up to eight independent states tracked by your remote (such as the power state on eight different device).

and the condition (toggle, test only, force on, force off) are.

ToadTog has a variety of uses that need those four operations, but for the typical simple use you want, only force on and force off are needed. You would have one ToadTog command that always leaves the remote believing the device is off and one that leaves the remote believing the device is on.

I'm also unclear how toadtog keeps track of a device state, especially after the remote is reset.

It can't.

ToadTog is an approximation of a real discrete. It can't be perfect. The remote has a "belief" about the state of the device. As long as that belief is right, the remote will send the right command and the device and belief will change together and remain correct.

Sometimes it will get out of sync. You need to have some shifted command that changes the state of the device (toggles its power) WITHOUT changing the state of the ToadTog flag. When you observe that the device state is out of sync with the remote's belief, you use that shifted key to bring the device into sync with the remote.

It may seem more reasonable to have the correction key toggle the remote rather than the device, to make the remote's belief match reality, and you could program it that way. But operationally you'll discover that a key to toggle reality to fit the remote is more convenient.

If the device gets out of sync too often, it isn't worth using ToadTog at all. If it gets out of sync rarely then ToadTog can be very convenient (ALMOST as good as having a device with real descrete codes). Whether it gets out of sync is a function of how you use the device (other remotes, power button on the device itself, bad air using your remote, etc.)

[sfhub]

Sometimes it will get out of sync. You need to have some shifted command that changes the state of the device (toggles its power) WITHOUT changing the state of the ToadTog flag. When you observe that the device state is out of sync with the remote's belief, you use that shifted key to bring the device into sync with the remote.

It may seem more reasonable to have the correction key toggle the remote rather than the device, to make the remote's belief match reality, and you could program it that way. But operationally you'll discover that a key to toggle reality to fit the remote is more convenient.

I used to do that, but I now use the "cover the IR emitter and press
Power" method of resyncing. It is simpler for me to remember than
the special shifted button I have also programmed.

Having said that, my ToadTogs are surprisingly almost never out of sync,
so they are a lot more useful than you'd think especially if your initial
reaction is they'll get out of sync so easily it isn't worth it.

[ElizabethD]

Last person, in this universe, I’d expect to toggle reality is John Fine

It may seem more reasonable to have the correction key toggle the remote rather than the device, to make the remote's belief match reality, and you could program it that way. But operationally you'll discover that a key to toggle reality to fit the remote is more convenient.

Why? What are the constraints in toggling the remote? Extender space? Remote itself? Just curious.

[johnsfine]

I should have realized that would need explanation.

Consider the typical usage case:

1) Initially the user doesn't know the remote is out of sync.

2) The user want to do some specific operation for which there is a macro to set everything up.

3) The user presses that macro and observes that one of the devices goes the wrong way (toggles when it was already in the desired state, or doesn't toggle when it wasn't yet in the desired state).

4) Now the remote thinks everything is in the desired state, but some device is in the undesired state.

5a) Corrected the way I suggest, you do the shifted command to put the device in the desired state, matcxhing both the remote and your intention. Correction done.

5b) Corrected the other way, you do something not affecting the device puting the remote into the undesired state to match the device in the undesired state. Correction is only half done.

6b) Next you must do another command to change the remote and the device to the desired state.

It isn't a big deal anyway and for some configurations the same analysis yields the opposite answer: The undesired state of the toggle would already have follow on consequences before it could be corrected, so step 6b would be needed for secondary reasons (so 5b would be better than 5a).

But in typical cases, it is more understandable and simpler to change the device to the state you intended it to be in, than to change the remote to know that the device is in the unintended state.

[The Robman]

But in typical cases, it is more understandable and simpler to change the device to the state you intended it to be in, than to change the remote to know that the device is in the unintended state.

Also, you can easily tell whether the device is in the right state (ie, you can see if it's ON or OFF) but the remote has no visible way of telling you what state it "thinks" the device is in. So, if you correct the sync issue by toggling the device, you get visual confirmation that it worked when you see the device turn off (or on), but if you toggled the remote's view of the device's state, you would not know if it worked until the next time you used one of your macros, and human nature being what it is, you're probably going to end up running a macro or something to confirm that the re-sync worked, which means you'd end up doing more "work" anyway.