R4 Queue Module?

vining

I finally decided to try the Queuing module since I'm still having issues on occasion which I'm assuming is cause by the DATA_Overflow - disconnect feature. I assuming this cause the repeater is in the room with the remote and yes on this job I used multiple repeaters to work with a single gateway. I thought it would be cool to roam with a remote but now I'd be happy if they would just work in the rooms they're supposed to.

Any way looking at the code it appears to really only benefit systems that are already controlling their feedback. If you tend to send feedback to an entire dvTPArray and not track which TP or remotes are actually on page then ths module may not be of much help. Unless I'm not reading this wrong the module only works on a port by port basis so it only manages or queues for each port and if your system is updating to dvTPArrays and multiple devices are updating simultaneously you can still potentially have 20 devices sending updates to the remotes at the same time and the overall feedback isn't queued.

Another reason to control feedback and only send to TPs and remotes their feedback if they are on that page for which feedback needs to be being sent otherwise the R4 needs a queuing module that queues all feedback from all devices.

Spire_Jeff

I thought the queuing module did take care of all ports, but I can't be sure about that. I recently revamped my code to specifically deal with R4s. There were a few places I was a little sloppy with code, but the bandwidth used for standard panels allowed this to exist without problems. The minute I tried the same code on an R4, problems began. I was/am controlling feedback, but there were commands being sent that absolutely did not need to be sent when a device was selected or a room was changed. By being very diligent in making sure that only the ABSOLUTELY necessary information is sent to the R4, it now works well.

I do have dedicated gateways for each R4, and if I recall correctly, each repeater halves the bandwidth. I should be ok with a single repeater, but I would not want to think about more than one repeater. As for interference, I have 5 R4s and 5 Gateways all within 5 feet of each other on the test bench right now and they seem to be working fine. They are all on the same channel (I haven't laid out my channel maps for the install yet). I have tried using multiple remotes simultaneously and they seem to work at about the same speed as using only a single remote.

I am using the queuing module and I am treating each module as stand alone so that no module ever sees more that 1 R4 connected.

Jeff

vining

Spire_Jeff wrote:

I thought the queuing module did take care of all ports, but I can't be sure about that.

You may be right. The instructions are a little vague but I can only guess that if you pass in the R4 base device and the virtual R4 base device of say 33012:1:0 in the module it will generate 19 more virtual devices 33012:2:0 to 33012:20:0 and work with anything virtual in your code that falls into this range. I'll further assume that the virtual port number must be the same as the real port number cuz that the only way I can see this working. Just swap the virtual dev.number with the real dev.number and send to the real device using the same .port and .system as the virtual.

I thought I needed an instance of the module for each virtual created cuz from the outside that's the only thing that initially makes sense. After further reading they are apparently doing more in the module expanding on the base virtual number. Nothing new but like always the instructions could be made clearer. I'd assume since they only allow 20 devices (virtuals) to work with the module that the port numbers being used have to no greater than 20. Of course with out clear documentation and a locked module who really knows.

I too have already modified my feedback to minimze what's going to the R4 regardless of the Queue module but not all my code is updated to only send feedback to the TP or remotes that are on specific device pages. That's a modify as I go process.

DHawthorne

Have you seen the new R4 and Zigbee firmwares? They only released a few days ago, and purport to address some of these issues. I'm a little gunshy to try them myself; care to be the guinea pig?

vining

DHawthorne wrote:

I'm a little gunshy to try them myself;

I hear ya! It seems lately everytime they come out with a new firmware or application and I install them the next couple of days are spent trying to undo the damage they've caused.

I loaded the R4 Queue Module today in the job having issues now the TV's aren't switching inputs and the FireBall doesn't correctly display text on the remotes so I removed the module and I'm back at sqaure one. Maybe if the module was open I could tweak it and at this point I don't feel like writing my own.

So maybe I should try the firmware since these remotes are halfway out the door any way. I've already had one stop working altogether that I replaced and another in the Master Bedroom the Mrs is getting fed up with. Maybe Zigbee should have been left to industrial sensors!

TrikinCurt

Once you get the queuing module going things will be much better, I don't send a ton of data to the R4 remotes which also helps (I don't let them be used to browse music lists for example), but as a remote with basic feedback and text updates the queuing module has got it to be a great remote for us (and I have two in my house that now work great as well).

Curt

vining

TrikinCurt wrote:

Once you get the queuing module going things will be much better,

That's what I was banking on but some stuff just stop working correctly after it was installed.

TrikinCurt wrote:

I don't send a ton of data to the R4 remotes which also helps (I don't let them be used to browse music lists for example)

Those are the kinds of things that got me excited about the R4 before its release. I've already trimmed back most of the fat that wouldn't be missed and the only thing left that would be considered bandwidth intensive is the FireBall movies & music. And if I can't display movies it's not worth installing.

For the most part they have worked rather well but they do hang up from time to time which could be due the the gateway buffer overflow disconnect or possibly RF interference from Panasonic cell stations and cordless phones since I have one in each room that has a remote.

It may be the way I initially set up this Zigbee network may part of the problem since this was back when they first came out and I felt having the ability to roam with a remote and control your house would be cool. Keep it in your pocket and view/change music, turn on lights, etc from anywhere. In order to accomplish this I created a star topology network consisting of 3 repeaters with a gateway at the center so that at no point would there be more than one hop to the gateway. I'm now thinking this may be fine for industrial sensors that send out a small burst of data every 30 second to a minute but maybe not so good for this application with these remotes.

I have another system to do in the next month which I'll set up as Spire_Jeff does with one gateway per remote and see if that helps any. If it doesn't then IMHO they aren't worth the aggrevation if at the end all I'm doing is basically just controlling the local TV. No music or movie lists then why bother.

The one thing I haven't done yet is verify all the repeaters are still online and communicating with the gateway. Although both remote show latency or sluggish performace it's the master bedroom remote that constantly hangs up and just stops working so it could be just a flaky remote causing my problems. Heck the other remote had to be replaced already when the numeric buttons just stopped working. I couldn't even enter the password to reboot it let alone reload any firmware.

BTW I updated the firmware and the module for the remotes and the firmware for the gateway and they still work.

I also just remotetly logged into the gateway and all devices are on line and all signal levels are "excellent"!

Spire_Jeff

I have used the R4 with fireball and with iPort. They are functional, but they are slow enough that you will see the list populate. I am talking about a couple of seconds, so it's not useless, just not as fast as a wireless TP.

Jeff