Home automation project is still under preparation (I don't even have the land yet haha), I'm beginning to plan the lighting part
I'd like to be able to dim my leds. I currently do that with a 12v DC bulbs and pwm. It works great but I would need to control it from 2 points : rotary encoder in the wall and via web interface (symfony).
Roatry encoder works great, instantaneous response time etc but I'd like to find a way to have a slider on my web interface that reacts instantly. Programming isn't the problem, I need advice regarding transmission.
I have tried esp8266, I get around 750ms delay between each change in pwm, I would need to drag this delay to down to ~10ms so this would be smooth
Solutions are :
dimmer is on switch side. Changing level on switch changes light instantly, then transmits pwm value to central command. Order from interface makes central command send pwm value to apply to the switch = high delay
dimmer is on control board : need to cable every bulb groups separately, switch sends pwm++ or pwm-- to the control board : delay, interface sends order to control board : delay too
I would love to avoid cabling everything (central command will be from 1 to 17 meters away from switches)
What do you propose?
Interface is on raspberry pi, control boards will be atmega2560 or smaller.
The problem is that you do not have any control over the exact timing of a web interface. Once you establish a connection, you can have real-ish time response, but there will always be an indeterminate delay when making the connection.
I'm guessing that your ESP8266 is directly controlling the lamp and if the WiFi of the ESP8266 connects directly to WiFi on an RPi (without going out to the the external internet) then based on my own limited tests I would expect an almost instant response - maybe a delay of 50 millisecs.
I'm not sufficiently familiar with WiFi and web programming to suggest what might be causing the delay.
It might be worth trying UDP which cuts out all the overhead of TCP. In theory UDP is unreliable because it does not do all the checking that TCP does but for short range local stuff it would probably be fine.
I did some UDP tests between my laptop and an ESP8266 that I was thinking of using for radio-control for a model train and the response seemed much the same as using nRF24L01+ wireless modules. IIRC the round-trip message time was about 2 millisecs. I gave up on the ESP8266 because it would be too power-hungry for my application.
It might be worth trying UDP which cuts out all the overhead of TCP. In theory UDP is unreliable
Yes it is, it can totally miss a transmission. Things will be going fine and then one is missed. This can be irritating in some contexts but down right dangerous in others.
Grumpy_Mike:
This can be irritating in some contexts but down right dangerous in others.
Agreed. But a significant delay in the receipt of a message can also cause problems. The system designer needs to figure out how to deal with these risks.
For example if the UDP sender expects a response and does not get it then it can repeat the message or warn the user that there is a communication problem.
Wires are more reliable provided the cat does not chew them.
Ok UDP is way faster but I realized my problem is that JS won't let me send UDP directly (and this would be unusable outside of my home network, even tho I would not use it.
The only way to work with JS is to use XML Http resquets, which are TCP and takes a few ms each, especially if I'm running a Symfony (unless cache is powerful enough)
