Scene too fast for gateway?

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.

ferpando

@olaeke
If you are able to turn 4 devices at the same time that is more than I can do at the moment. Maybe power is one of the issues as @Zeph suggested, but not the only one.

ferpando

@hek
I'll try lowering the rate after upgrading the powersupply. Maybe this will also help a bit more.
About the buffer, would an ethernet gateway behave better in this matter?
Maybe all this could resolve itself changing gateway type?

ferpando

Powered hub alone did not make any improvements.
I'll try bigger capacitor next.

ferpando

10 mF also no change. I'll try someting bigger when i can

ferpando

@hek
I recompiled the gateway with 9600 bauds but the vera plugin won't start if not 115200.

Any way to change this without messing everything up?
I reuploaded L_Arduino.lua changing the setting but vera does not use the new file. I can see both in the list.
I'll try to delete both via ssh and reupload to see what happens

Scene too fast for gateway?

20

11.7k

11.2k

113.0k