Odd R4 / code problem

Bigsquatch

I have a multi-room AV project that I am controlling with an R4 remote and an NI-3100. To make things as easy for the user as possible (trust me, it has to be) I put channel codes on the external R4 power button on every page to turn the system off. Problem is is that the power button will work the 1st time after the code is uploaded but then only works on rare occasions after that.

Things I have checked / ruled out:

'Override Global Settings' on power button is set to yes

Channel code IS being sent to master every time as verified by device monitoring in NS

Firmware on ALL devices, let me repeat that to be absolutely clear, firmware on ALL devices is up to date: R4 firmware, R4 Zigbee module, Zigbee gateway firmware, NI firmware

Added variable called dbug to toggle from every time code block is executed from 1 to 0 or vice versa as appropriate. It toggles 1st time as expected but then no more. And before you say it, the toggle code is correct because it does toggle every time I do a virtual button press by using emulate a device.

Checked code and TP file for duplicate channel codes that could be causing problems (there are no other R4's or keypads or touch panels either)




And I am using 2 different channel codes depending on which page the user is on and the same behavior occurs with both of those channel codes!

Here are the code blocks

BUTTON_EVENT[dvR1_P3,14]	// Turn Off TV
{
  PUSH:
  {
	if (dbug = 0) 
		{ dbug = 1 }
	else 	{ dbug = 0 }
  
   SEND_STRING dvAutoPatchPrecis, "'DL0O',ITOA(master_r4_zn),'T'"
	SWITCH (master_r4_zn)
	{
	   CASE 1: { PULSE[dvMST_TV,152] }
	   CASE 2: { PULSE[dvOFF_TV,130] }
	   CASE 4: {
		PULSE[dvFAM_TV,2]
		wait 10 { PULSE[dvFAM_AMP,35] }
	   }
	}
   }
}

BUTTON_EVENT[dvR1_P3,15]	// Turn Off TV from DVD page
{
  PUSH:
  {
   SEND_STRING dvAutoPatchPrecis, "'DL0O',ITOA(master_r4_zn),'T'"
	SWITCH (master_r4_zn)
	{
	   CASE 1: { 
		PULSE[dvMST_TV,152]
		PULSE[dvMST_DVD,2]		// Stop DVD
	   }
	   CASE 2: { 
		PULSE[dvOFF_TV,130]
		PULSE[dvMST_DVD,2]
	   }
	   CASE 4: {
		PULSE[dvFAM_TV,2]
		WAIT 10 { PULSE[dvFAM_AMP,35] }
		WAIT 20 { PULSE[dvMST_DVD,2] }
	   }
	}
   }
}

the master_r4_zn variable is not the problem either. I've monitored it and the value is always correct and besides that the dbug variable should toggle even if master_r4_zn were to get messed up.

Any ideas?

NMarkRoberts

If I read you correctly (please confirm), NS2 notifications is showing a button press arriving, but your code isn't seeing it; the device is not a virtual device, so there can't be any intervening code getting in the way; and it works correctly in "Emulate a device".

I feel that the dbug thing isn't a reliable way to show that the code is seeing button presses. If it is toggled twice in quick succession you might not see it happen.

I suggest you add this:

button_event[dvR1_P3,0]
  {
  push: send_string 0,"'Push[',itoa(button.input.channel),']'"
  release: send_string 0,"'Release[',itoa(button.input.channel),']'"
  hold: send_string 0,"'Hold[',itoa(button.input.channel),']'"
  }

you can see these messages by telnetting into the master and entering "msg on".

If that doesn't give you a useful clue, I think you need to reduce your code to the absolute minimum that demonstrates the problem. I'm guessing that as you progressively remove other code or other factors you will find the cause.

Bigsquatch

NMarkRoberts wrote:

If I read you correctly (please confirm), NS2 notifications is showing a button press arriving, but your code isn't seeing it; the device is not a virtual device, so there can't be any intervening code getting in the way; and it works correctly in "Emulate a device".

Yes that is correct. Thank you for the suggestion.

Darkside

nMarkRoberts comment about the dbug flag is very valid. Another approach is to increment your dbug flag - dbug++ and watch how many times the routine is firing - or firing at all.

Stick it inside the CASE statements though to prove the case is executing and not just seeing your push!

The other suggestion is to use the SP send_command.

If the command is being rx'd from the R4 twice for some odd reason, then the IR commands will get spat out twice - almost at the same time and they therefore probably won't work.

The SP send_command method stacks your IR commands so they can't bump into each other. Very valuable if there are several remotes accessing the same dev.

HTH

a_riot42

NMarkRoberts wrote:

If I read you correctly (please confirm), NS2 notifications is showing a button press arriving, but your code isn't seeing it; the device is not a virtual device, so there can't be any intervening code getting in the way; and it works correctly in "Emulate a device".

I feel that the dbug thing isn't a reliable way to show that the code is seeing button presses. If it is toggled twice in quick succession you might not see it happen.

I suggest you add this:

button_event[dvR1_P3,0]
  {
  push: send_string 0,"'Push[',itoa(button.input.channel),']'"
  release: send_string 0,"'Release[',itoa(button.input.channel),']'"
  hold: send_string 0,"'Hold[',itoa(button.input.channel),']'"
  }

you can see these messages by telnetting into the master and entering "msg on".

If that doesn't give you a useful clue, I think you need to reduce your code to the absolute minimum that demonstrates the problem. I'm guessing that as you progressively remove other code or other factors you will find the cause.

From the example code above, this:

hold: send_string 0,"'Hold'

will never get printed.
Paul

NMarkRoberts

It wouldn't compile, oops, try this:

button_event[dvR1_P3,0]
  {
  push: send_string 0,"'Push[',itoa(button.input.channel),']'"
  release: send_string 0,"'Release[',itoa(button.input.channel),']'"
  hold[10]: send_string 0,"'Hold[',itoa(button.input.channel),']'"
  }

I think we've covered this in a different thread, but note that the hold behaves very oddly.

(a) It always fires, no matter how short the push.

(b) Sometimes it fires after the release.

(c) It always reports channel 0.

(d) If you add a repeat it fires every second whether you push or not!

  hold[10,repeat]: send_string 0,"'Hold[',itoa(button.input.channel),']'"

The same code without the channel wildcard works correctly.

button_event[dvR1_P3,1]

Bigsquatch

Well NMR is right, the button presses are not showing when monitoring through telnet (except for the 1st press after a reboot.)

I have commented the source down to just 6 lines of code plus the code NNMarkRoberts posted for monitoring button presses. It's nothing more than 1 device definition (and only 1 port of that device) plus 2 empty button events and...























...the behavior is exactly the same!

I even rebuilt the R4 TP file starting with a new file and copying and pasting pages into the new file.

I am on hold with tech support right now.


EDIT: Gave up on tech support for today, but I noticed that the button press seems to go through whenever the R4 reconnects. For example, if I walk with it from one end of the house to the other, when it re-establishes a connection the button works (1 time.) That doesn't give me any ideas but it may help when I finally am able to get a hold of tech support.

vining

Go to NS2 and in diagnostics enable push message status bar display. Push the buttons and see what you get displayed. If you get what you should then comms are working and your TP pages are correct but if you get nothing then you likely have comm problems or you might get the wrong DPS but if that were true why would it work sometimes.

You put in the send_string 0s that NMarkRoberts suggested so what do you see when in diagnostics? Anything? Regardless of what your code does or doesn't do if the system is seeing the push/release it should print the string (,"'Push'"
)

Bigsquatch

Update: Problem solved.

The R4 is not triggering a button release so any subsequent pushes have no effect.

I have temporarily fixed the problem by waiting a few seconds after the push and then using DO_RELEASE(dvR1_P3,14)

I also have a RMA request in for the R4.


Thanks to everyone who replied. Many of your suggestions helped me diagnose this problem.

Bigsquatch

Bigsquatch wrote:

Update: Problem solved.

The R4 is not triggering a button release so any subsequent pushes have no effect.

I have temporarily fixed the problem by waiting a few seconds after the push and then using DO_RELEASE(dvR1_P3,14)

I also have a RMA request in for the R4.


Thanks to everyone who replied. Many of your suggestions helped me diagnose this problem.

So I received the new R4, uploaded the panel file, got it on the zigbee network and tested the system. Power button works just like it should. It shut the system down several times with no reboots as expected.

After 7 to 10 times testing it with different sources in different rooms, it STOPPED FRIGGIN' WORKING! I added the monitoring code back to the project and monitored via telnet and it has the same D&$%! problem. It never triggers a release.

So I added my DO_RELEASE fix back to the code and left it. Very disappointing.

Spire_Jeff

Have you added the R4 throttling code provided in a different thread here? That might help alleviate the problem. I know it made our R4 work better.

Jeff