Scene too fast for gateway?
-
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\nwithout 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\nDuring 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\nas I hint - I hope I'm wrong :)
- Pit
-
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?@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 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. ;)
@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?
-
@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?
@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 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.
@BulldogLowell I have some 10mF. Would this be enough or do you suggest somthing bigger...
-
@BulldogLowell I have some 10mF. Would this be enough or do you suggest somthing bigger...
-
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.
-
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.
@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.
-
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#L38And in the Vera serial configuration.
-
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.
-
@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.
-
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#L38And in the Vera serial configuration.
@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? -
Powered hub alone did not make any improvements.
I'll try bigger capacitor next. -
10 mF also no change. I'll try someting bigger when i can
-
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#L38And in the Vera serial configuration.
@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 -
After deleting the files and reuploading the 9600 version, nothing changed, so this is not the problem.
From the lua file, I see there is a function that sends the data to the nodes.
How does it work? Is it invoked by vera when you push some button?Would it be too complex to make the function store command on an array for instance and send a command to a node from that array queue and not sending another until acknowledge is recevied?
-
After deleting the files and reuploading the 9600 version, nothing changed, so this is not the problem.
From the lua file, I see there is a function that sends the data to the nodes.
How does it work? Is it invoked by vera when you push some button?Would it be too complex to make the function store command on an array for instance and send a command to a node from that array queue and not sending another until acknowledge is recevied?
-
Perhaps you could do some research buffering the outgoing messages.
I think they all requires ack back from nodes today so this new feature could also try to resend non-acked messages after some timeout.
@hek
Nothing seems to work.
I will upgrade the capacitor for the radio but I don't have many expectations.As for the plugin, I would need to know more about how vera works.
Is there a main function in the plugin?
Also, how do you debug the code in vera? -
The closest to "main" is this:
https://github.com/mysensors/Vera/blob/master/L_Arduino.lua#L543Debugging isn't easy. I usually ssh:ed into the box and tailed the logfile. Was also able to mount the NAS from Vera so I didn't have to scp/file upload changes.
