Scene too fast for gateway?

[ferpando]

@hek
I've been trying some things and the problem is consistent.
If I turn on/off 2 or more devices on a scene at the same time, not all work.
The message to some devices is lost never reaching its destination.

How does the plugin handle this? Does it have some kind of buffer?

From the node point of view, if 2 messages arrive too fast, what happens?
If the arduino is busy doing something, will it receive the next message when it finishes processing?

I don't know how to solve this. Just the 2-3 second delay between messages is working, but it is a bit annoying and not very practical.

[BulldogLowell]

@ferpando said:

I don't know how to solve this. Just the 2-3 second delay between messages is working, but it is a bit annoying and not very practical.

When applying an action from vera to multiple devices, I use a short delay in the scene for each device to allow the transmissions time and the radio to repond. There is the power aspect, and the serial processing aspect to deal with.

With vera's delay capability built in to the scene, I find it only mildly annoying, but not at all impractical:

[ferpando]

Yes, tha's exactly what I do, but is not the best solution.
It would be best is the system (plugin) had some kind of buffer and the nodes didn't get the next message from the gateway until the arduino was free to process.
Maybe checking for messages in the main loop?
I don't really know how the system works right now, but messages are lost if sent too fast.

[BulldogLowell]

@ferpando said:

but is not the best solution.

yeah, I agree. I ran into this early on but never thought about it since. I actually use luup attached to a scene rather than using the pushbutton controls. I can then use luup.sleep( ) function to allow a little time back to the controller... and I see all the actions on a single page:

luup.inet.wget("192.168.1.50//?alarmState=0&", 1)
luup.sleep(500)
luup.inet.wget("192.168.1.50//?airconSetpoint=74&", 1)
luup.sleep(500)
os.execute("curl -k https://api.spark.io/v1/devices/"..sparkDeviceID.."/httpRequest  -d access_token="..sparkAccessToken.."  -d params=command#garageState#text=NULL#value0=0#value1=0?" ,1)
luup.sleep(500)
os.execute("curl -k https://api.spark.io/v1/devices/"..sparkDeviceID.."/httpRequest  -d access_token="..sparkAccessToken.."  -d params=command#airconSetpoint#text=NULL#value0=72#value1=0?" ,1)

if you want to try writing some code I'm happy to help you test, and I'm sure others would too.

[ferpando]

That would be ok for 2 or 3 devices, but if you need to turn on let's say 5, waiting all those seconds is no good. Epecially if they are lights.

I have some Chacon DI·O 433Mhz plugs controlled by rfxcom and I can turn 10 of them off without problem. They just go one after the other but very quickly.

That's why I guess the problem is in the plugin that sends messages too fast for the nodes.

Any of the programmers have some clue about this?

[olaeke]

@ferpando I have actually exact the same problem right now but I expect that the Vera Edge is the problem. I looks like some devices are present in the scene but they are still not present. I have created a scene with about 10 devices in and that looks ok in the scene but when I look on the "scene info" on each device then some of them doesn't says that i exist in that scene. I have also made a quick check on the serial debug and it looks like the Vera doesn't send command for all devices. Right now I'm recreatcing my scene to verify that all devices actually are included.

I'll be back....

[BulldogLowell]

@ferpando said:

I guess the problem is in the plugin that sends messages too fast for the nodes.

the dalays don't need to be that long... just an example...

one of the issues you may face could be power available to the radio when you transmit. Do you have a capacitor on the gateway radio power already? if so, look at the output from the Serial monitor when you transmit, you may be able to see what's happening there. What type of power supply are you using on the gateway?

FYI your arduino has a 64byte serial buffer and the NRF24L01 a 32byte buffer. A software alternative may be to add a little delay in parseAndSend( ) in MyGateway.cpp or just before that function call in your SerialGateway.ino or EhternetGateway.ino files, just so that you allow a little time for the buffer on the radio to clear out and the cap to recharge before sending the next message.

on the Ethernet:

  Serial.print(inputString);
  delay(35);  // <<<<<<<<<<<<<<<<<<<<<<<< here, you can start with an imperceptible number like 35ms
  gw.parseAndSend(inputString);

[ferpando]

@BulldogLowell
I use the VERA's USB to power my serial gateway.
Would an ethernet gateway behave better?
I tried adding the delay but all I get is a lot of fails in the messages. Maybe the gateway is busy waiting and doesn't catch new messages?
This is the log from the node:

read: 0-0-6 s=0,c=1,t=2,pt=0,l=1:0
send: 6-6-0-0 s=0,c=1,t=2,pt=0,l=1,st=fail:0
--> Incoming change for relay:0, New status: OFF
Time ms: 1
************************************************
read: 0-0-6 s=0,c=1,t=2,pt=0,l=1:0
send: 6-6-0-0 s=0,c=1,t=2,pt=0,l=1,st=ok:0
--> Incoming change for relay:0, New status: OFF
Time ms: 1
************************************************
read: 0-0-6 s=0,c=1,t=2,pt=0,l=1:1
send: 6-6-0-0 s=0,c=1,t=2,pt=0,l=1,st=ok:1
--> Incoming change for relay:0, New status: ON
Time ms: 1
************************************************
read: 0-0-6 s=0,c=1,t=2,pt=0,l=1:1
send: 6-6-0-0 s=0,c=1,t=2,pt=0,l=1,st=fail:1
--> Incoming change for relay:0, New status: ON
Time ms: 1
************************************************
read: 0-0-6 s=0,c=1,t=2,pt=0,l=1:1
send: 6-6-0-0 s=0,c=1,t=2,pt=0,l=1,st=fail:1
--> Incoming change for relay:0, New status: ON
Time ms: 1
************************************************
read: 0-0-6 s=0,c=1,t=2,pt=0,l=1:1
send: 6-6-0-0 s=0,c=1,t=2,pt=0,l=1,st=fail:1
--> Incoming change for relay:0, New status: ON
Time ms: 1

Your other option adding delays in code and call devices also in code seams to work for now. Something like this:

local myDelay=300;
luup.call_action("urn:upnp-org:serviceId:SwitchPower1","SetTarget",{newTargetValue="1"},219)
luup.sleep(myDelay)
luup.call_action("urn:upnp-org:serviceId:SwitchPower1","SetTarget",{newTargetValue="1"},221)
luup.sleep(myDelay)
luup.call_action("urn:upnp-org:serviceId:SwitchPower1","SetTarget",{ newTargetValue="1"},216)

I'm gonna explore more this option and get back to you.

[ferpando]

If I use the above code with the delays in lua, it seams to work:

read: 0-2-6 s=0,c=1,t=2,pt=0,l=1:1
send: 6-6-2-0 s=0,c=1,t=2,pt=0,l=1,st=ok:1
--> Incoming change for relay:0, New status: ON
Time ms: 1
************************************************
read: 0-2-6 s=1,c=1,t=2,pt=0,l=1:1
send: 6-6-2-0 s=1,c=1,t=2,pt=0,l=1,st=ok:1
--> Incoming change for relay:1, New status: ON
Time ms: 1
************************************************
read: 0-2-6 s=2,c=1,t=2,pt=0,l=1:1
send: 6-6-2-0 s=2,c=1,t=2,pt=0,l=1,st=ok:1
--> Incoming change for relay:2, New status: ON
Time ms: 1
************************************************
read: 0-2-6 s=3,c=1,t=2,pt=0,l=1:1
send: 6-6-2-0 s=3,c=1,t=2,pt=0,l=1,st=ok:1
--> Incoming change for relay:3, New status: ON
Time ms: 1
************************************************
read: 0-2-6 s=4,c=1,t=2,pt=0,l=1:1
send: 6-6-2-0 s=4,c=1,t=2,pt=0,l=1,st=ok:1
--> Incoming change for relay:4, New status: ON
Time ms: 1
************************************************
read: 0-2-6 s=5,c=1,t=2,pt=0,l=1:1
send: 6-6-2-0 s=5,c=1,t=2,pt=0,l=1,st=ok:1
--> Incoming change for relay:5, New status: ON
Time ms: 1

but if I use the devices on the scenes, the result I get is this:

read: 0-2-6 s=0,c=1,t=2,pt=0,l=1:1
send: 6-6-2-0 s=0,c=1,t=2,pt=0,l=1,st=ok:1
--> Incoming change for relay:0, New status: ON
Time ms: 0
************************************************
read: 0-2-6 s=1,c=1,t=2,pt=0,l=1:1
send: 6-6-2-0 s=1,c=1,t=2,pt=0,l=1,st=ok:1
--> Incoming change for relay:1, New status: ON
Time ms: 0

only 2 of the 6 are received.

If I lower the delay too much I also start to miss some of them.

[pit007]

I don't have vera but my 5 cent:

If two or more commands send at the same time they can be packed in the same tcp package.

with delay (4 tcp packages)
12;6;0;0;x;1\n
12;6;0;0;x;2\n
12;6;0;0;x;3\n
12;6;0;0;x;4\n

without delay: (2 tpc packages - the first with 3 commands)
12;6;0;0;x;1\n12;6;0;0;x;2\n12;6;0;0;x;3\n
12;6;0;0;x;4\n

During my walk throug the sources of different MYS impementations I didn't see code to parse the second case correctly - so with commands following in shoort time behind, the receiver see only the first command in a package:

12;6;0;0;x;1\n
12;6;0;0;x;4\n

as I hint - I hope I'm wrong :)

• Pit

[ferpando]

All this was on a test board.
Now I'm trying it in the real world and it doesn't work.

I noticed nodes have radio power set to max and gateway to low by default.
Why is this?
Maybe increasing gateway radio power would help?

[hek]

@ferpando said:

I noticed nodes have radio power set to max and gateway to low by default.
Why is this?

Basically a safety thing. Many used the amplified NRF module on their gateway without feeding it with enough power. This resulted in failed transmissions and more support. ;)

[ferpando]

@hek
So it would be ok to increase radio power on the standard version without causing problems?

I noticed if I put the antenna inside a plastic box starts to fail a lot. But the distance is not much, 4m at the most.

Also increasing datarate could help with this problem? If data is sent faster, maybe works better?

[BulldogLowell]

@ferpando said:

I use the VERA's USB to power my serial gateway.

and you have a capacitors on the radios, yes? I'm not sure if there is really enough power from the vera to keep up with the radio, so beefing up the cap may help too.

makes a huge difference... having lots of power available for the multiple bursts of the radio.

[ferpando]

@BulldogLowell I have some 10mF. Would this be enough or do you suggest somthing bigger...

[BulldogLowell]

@ferpando

that would be a good start. @hek recommends starting at 4.7µF but I have seen folks here swear they need much bigger.

It depends, as you may know, on the power supply as well. Some folks may even have moved the USB gateway off to a powered USB hub.

[Zeph]

Has it been determined that the messages are getting to the gateway's radio (transmitter)? If so, then caps on the nRF24L01's power supply may indeed help if power sag is the issue; if not, then we're looking in the wrong place and some of the other suggestions may be relevant.

IF it's about power sag in the radio, that may require large caps. Sometimes small caps help the radio, if it's having problems with high frequency spikes and noise in the power supply. But if the problem occurs over hundreds of uSec (one packet affecting the following one) then it would be very low frequency and relatively long duration.

However, a better power supply would be a better solution if so. A scope (even an arduino based software scope given the frequencies involved) might help determine if the supply is really the problem.

AND of course, the first question is whether the controller firmware is even TRYING to send every packet, as this post began.

[olaeke]

@Zeph I dont't think it has to do with the powersupply. I have the same problem and I power my Gateway with 2A supply and on the radio I have 47uF. I have a coulple of scenes that turn on/off lamps and in my case it looks like there is a limit around 4 devices, if the scene contains more than 4 devices whith no delay then it often miss some of them. But when I added 1 sec delay between every third device then it works fine.

[hek]

Could it be the serial buffer of the arduino (64 bytes) that fills up to quick with the baudrate?

What happens if you lower baudrate to say 9600?

Change here and re-compile gateway:
https://github.com/mysensors/Arduino/blob/master/libraries/MySensors/MySensor.h#L38

And in the Vera serial configuration.

[ferpando]

@Zeph
As you can see in the log above, the gateway starts to send messages and only the first and second reach the corresponding node.
Maybe it is a power issue. I'll try a powered hub and see what happens.