Let's Control It

Hi,
I've got a Node-RED flow that sends MQTT commands to turn three LEDs (Red, Yellow and Green on a WeMos D1 Mini) on/off to mimic the UK traffic light sequence.

Although it works fine, there is a perceivable delay between one LED going off and the next one coming on.

I've tried changing some of the MQTT settings in ESP Easy and got a slight improvement but not great.

Is there something else I could do, or am I stuck with this??

Kind regards from David.

Running MQTT from Openhab towards quite a lot of ESPEasy's. They all switch almost instantaneous, so maybe your problem is with the broker?

Thanks for the 'heads-up' on that - I'll try to check it out.

Do you run 'mosquitto' on a Raspberry Pi by any chance??
If so, could you share your 'conf' file??

Cheers from David

I'm running Mosquitto on a virtual Windows 10 PC together with Openhab. You could try using a MQTT client on your own PC and listen to the same topics as your ESP8266 device. Then you'll get an idea of where the delay is. You can also publish from most clients (Use https://mqttfx.jensd.de/ myself).

My Mosquitto config is 100% standard, so no changes at all.

I am just wondering if you can set the sequence via rules, rather than the broker sending individual messages for each color change.

Are these simple traffic lights or are there turning arrows?

I hope you have included a Red Light traffic enforcement camera.

Yes I'm also in favor of having rules (timers) setting the color. You can then also have events that will override those timers and set a specific color. Using event values makes you also able to enable the timers to be activated again after a set time.

Hi guys,
Thanks for the suggestion about using 'rules' - I had completely overlooked 'rules'.

The Node-RED flow (which I can post if anyone is interested) just decodes a decimal counter to drive three MQTT Out nodes that opearte the three LEDs.
I've looked at the ESP 'log' and can see that there are three MQTT transfers for each change in the traffic light sequence!!!
That means the NR flow is sometimes turning off an LED that is already off (if you get what I mean).
I'm sure using 'rules' I could trim that down.

Well you know what my task is for this morning.

By-the-way, using 'rules' and 'events' will make an interesting session for my IoT students.

Cheers from David.

Yep we will improve the rules engine in the month after the first stable release. That means that more events will handled and possible to act upon.

If anyone is interested, here's a listing of the rules for my traffic light sequencer.
It receives an event from Node-RED via MQTT that simply sends a value between 0 and 3.
All the rules do are decode the decimal value and turn apprppriate leds ON/OFF.

Cheers from David.


// Decode %eventvalue% for the counter event to turn appropriate led On/OFF
//
// D8 (GPIO-15) is connected to RED led
// D7 (GPIO-13) is connected to YELLOW led
// D6 (GPIO-12) is connected to GREEN led

on counter do
if %eventvalue% = 0 // Turn RED led ON
GPIO,15,1
GPIO,13,0
GPIO,12,0
elseif %eventvalue% = 1 // Turn RED and YELLOW leds ON
GPIO,15,1
GPIO,13,1
GPIO,12,0
elseif %eventvalue% = 2 // Turn GREEN led ON
GPIO,15,0
GPIO,13,0
GPIO,12,1
elseif %eventvalue% = 3 // Turn YELLOW led ON
GPIO,15,0
GPIO,13,1
GPIO,12,0
endif
endon

dynamicdave wrote: ↑30 Oct 2018, 09:44The Node-RED flow (which I can post if anyone is interested) just decodes a decimal counter to drive three MQTT Out nodes that opearte the three LEDs.

Hi David, please post your Node-RED flow, I'm interested to see this one.

Here's a link to a detailed document that explains how to build a traffic light sequence and other patterns.

It basically uses a function block as a decimal counter followed by other function blocks that act as decoders.

http://resources-area.co.uk/node-red-fl ... quence.pdf

Hope you find it useful.

Cheers from David.