NR kind of doing it's own thing

General
1

I have a Raspi 3B which has the 64bit minimal o/s installed and Mosquitto.
There is also an Arduino Mega with an ethernet hat and dmx hat.
There are 10 x Sonoff switches with the Tasmota software installed for remotely powering devices on/off
There are 5 theatre lights with pan, tilt, colour, dimmer etc channels.
These lights are powered up via the Sonoff switches and then dmx commands are issued from NR to the Arduino Mega via ethernet and go out to the theatre lights via the dmx hat.

In the NR dashboard a single button sequentially turns all the 10 Sonoff switches on with a 3 second delay between the on command to each Sonoff.

As the theatre lights take about 20 seconds to initialise, there is a 25 sec delay for each light before I send a pan, small delay then tilt, small delay then colour, small delay then dimmer setting.
Repeat for each light.

A week ago when I wrote the flow, all was working. The lights sequentially turned on, initialised and each went to a pre determined location with colour and brightness.

Now, a week later, they all turn on fine but move the the last position they were in, with last known colour and brightness.

NR has been re-booted, Arduino has been power cycled and I just don't understand why they ignore the flow sequence.

Each light has its own page and all the pan, tilt etc commands work from there so it is not that the dmx has failed.

Is it possible I have too many delay nodes on the page?
Simply, most of the nodes are being ignored.
Is it possible something is buffered somewhere that needs flushing?
I tried moving some nodes so the flow had to be re-deployed.

I'm so confused.
Sorry for no code copied up but there are so many pieces, it seemed easier to identify the parts.
What worked a week ago has decided to not bother anymore.

Any ideas welcomed.

2

Add debug nodes to the flow after each relevant node and work out at what point it is failing.

3

That is a good idea, thank you.
I have started doing that.

4

I thought I would put a quick response.
Having put some time into this I think there are two observations worth noting.
Firstly, as part of the ESP code which I used there was a section sending 'Last Will & Testament' messages. So when the device was re-powered after being turned off I think this might have generated a message that was over riding the start up settings.

Secondly, I have found that when using the MQTT Out node, if I send the same message two times within a few seconds the node does not send the second message at all. I don't have an idea as to why this is true but my workaround was to send a fake message followed by the real message.

All my issues were on start up, whereas, once the devices were up and on the WiFi they respond as expected.

Anyway somewhere between the above points identified I have found enough of a workaround to satisfy me for now.
Thanks to all those who read the message and the respondents.

5

I think that is most unlikely. What tells you that the second message is not sent?

6

I used a trigger node with a 3 second resend and a debug node on the output side of the trigger.
Also used MQTTBox on a win machine to monitor the topic and it only received one message.

But now I am doubting myself again. I can't check until later in the week now as it is not a system I have daily access to.
I just did a test on my home environment and did get both messages but I don't have the exact reference to the one that is causing me the problems here and now.

I do appreciate your replies, I am trying to get better at this and suddenly I further doubt myself again.

The last will and testament stuff was a problem. I also upgraded from Raspi 3 to Raspi 4 which as I understand has a proper ethernet port. As at power up there are a lot of devices coming online (between 25 and 30) which all have to gain wifi access and subscribe to their various topics so it is busy at startup.

Again thanks for assisting.

7

Add an MQTT In node subscribing to the same topic that you are publishing to.
Then add a Debug node showing what is going into the MQTT Out node, and another showing what is coming out of the MQTT In node. You should see every message that appears on first debug node then appear also from the second debug node.