Using two mqtt controllers same time

[bonti69]

Please note that this is not just having 2 of the same MQTT controllers, but just any combination of MQTT controllers as they do share a lot of common code. (only the platform specifics like message formatting differs)
For any combination of MQTT controllers, only the first enabled MQTT controller will be considered when you use commands like publish or use the MQTT import plugin.
A MQTT client needs to make a connection to a broker and since there is (at most) only a single MQTT client instance running in ESPEasy, you simply cannot have multiple MQTT controllers connect to different MQTT brokers at the same time.

For ESP8266 it simply would not work as we don't have enough free resources available (mainly memory)
But also for ESP32-xx quite a lot needs to be changed to allow to have multiple MQTT controllers active at the same time:

- Look at max. nr of open connections
- Make sure no global or static variables/objects are being used by a MQTT controller
- MQTT scheduling code needs to be changed
- MQTT related commands (e.g. 'publish') need to be adapted to include a parameter to what controller should be used
- MQTT pubSubClient library needs to be adapted to have multiple instances running on the same unit
- Special case for when 2 controllers are configured to connect to the same MQTT broker.
- Received commands via MQTT must all be looked at to see where any reply/ack must be sent to (extend command source/origin handling code)

And probably quite a few more changes are needed.
But like I said, there currently is no other similar firmware (ESPHome/Tasmota/ESPruna/etc) which supports connecting to multiple MQTT brokers, not even Home Assistant itself.

Thanks TD-er for your kindly explanation

[bonti69]

Please forgime me if I just insist a little bit over the subject. I understand for a small ESP device it's sufficent to deal with one mqtt broker, one at a time. Just want to play with 2 controllers, periodically enabled/disabled alternativelly, in order to send data to 2 controllers, forcing nature. As an experiment

[bonti69]

Hello again,
Started to play with two controllers flip flop.
I have a 4MB ESP12s board with a HTU sensor attached

Screenshot 2024-12-08 at 11-56-28 X19.png (100.3 KiB) Viewed 4991 times

Task1 send data to controller2, aka local homeassistant and task5 should send data to remote mqtt, controller1 but it doesn't
I made a rule, every minute, for testing: every minute controller2 is disabled for 15sec and taskrun5 seems not sending any data to mqtt1 server

Code: Select all

On Clock#Time=All,**:** Do
ControllerDisable 2
ControllerEnable 1
TaskRun 5
timerSet,2,15
Endon

On Rules#Timer=2 do
ControllerDisable 1
ControllerEnable 2
Endon

I tried on task5 to set interval 5s, 0 ... same result, not sending anything. Should I use "publish mqtt" command or I'm missing something?

Screenshot 2024-12-06 at 00-24-56 X19.png (65.36 KiB) Viewed 4986 times

Checked the status of controllers, works accordingly: controller1 enabled 15s / controller2 disabled , then controller2 enabled 45s / controller1 disabled

[bonti69]

In mqtt explorer, without flip/flop rule, HA mqtt enabled,aka controller2 everything works as expected

mqtt2.jpg (108.73 KiB) Viewed 4988 times

With rule flip/flop enabled, I have this

mqtt with rule enabled.jpg (116.13 KiB) Viewed 4988 times

Notice , in HA broker appears cloud with two entities, custom1 and custom2, but Task 5 should send data only to controller 1, not to controller2.

And the data collected by task5 , send data to controller2 instead of controller1, so I have no data sent to controller1

[bonti69]

Tried a delay of 2s after enabling controller 1, no effect

Code: Select all

On Clock#Time=All,**:** Do
ControllerDisable 2
ControllerEnable 1
//TaskRun 5
timerSet,2,15
timerSet,3,2
Endon

On Rules#Timer=3 Do
TaskRun 5
Endon

On Rules#Timer=2 do
ControllerDisable 1
ControllerEnable 2
Endon

Log

Code: Select all

186623771: P014: Temperature: 24.37 Humidity: 41.10
186623784: EVENT: HTU#Temperature=24.4
186623793: EVENT: HTU#Humidity=41
186625889: EVENT: Rules#Timer=1,1
186625897: ACT : TaskValueSet 5,1,24.4
186625906: ACT : TaskValueSet 5,2,41
186625911: ACT : timerSet,1,10
186630560: EVENT: Clock#Time=Sun,13:23
186630568: ACT : ControllerDisable 2
186630572: ACT : ControllerEnable 1
186630575: ACT : timerSet,2,15
186630579: ACT : timerSet,3,2
186632745: EVENT: Rules#Timer=3,1
186632751: ACT : TaskRun 5
186632755: Dummy: value 1: 24.4
186632756: Dummy: value 2: 41
186632776: EVENT: cloud#All=24.4,41
186636188: WD : Uptime 3111 ConnectFailures 0 FreeMem 18864 WiFiStatus: WL_CONNECTED 3 ESPeasy internal wifi status: Conn. IP Init
186637755: Dummy: value 1: 24.4
186637756: Dummy: value 2: 41
186637770: EVENT: cloud#All=24.4,41
186645421: P014: Temperature: 24.37 Humidity: 40.80
186645431: EVENT: HTU#Temperature=24.4
186645437: EVENT: HTU#Humidity=41
186645577: EVENT: Rules#Timer=2,1
186645585: ACT : ControllerDisable 1
186645590: ACT : ControllerEnable 2
186647890: EVENT: cloud#All=24.4,41
186652759: Dummy: value 1: 24.4
186652760: Dummy: value 2: 41
186652765: EVENT: cloud#All=24.4,41
186657822: Dummy: value 1: 24.4
186657824: Dummy: value 2: 41
186657827: EVENT: cloud#All=24.4,41
186662755: Dummy: value 1: 24.4
186662757: Dummy: value 2: 41
186662760: EVENT: cloud#All=24.4,41

Autoscroll: 

[TD-er]

I have just read your posts very briefly.
Maybe there is some issue where you need to wait for the MQTT#connected event before sending data?
Otherwise it may not be sending out data as it is not considered 'connected'.
The published messages should end up in the controller queue, but maybe things will be retried again and then the queue flushed.

So I think maybe these steps will make it less timing critical:
- Call controllerdisable
- Wait for mqtt#disconnected event and when handling that one, call controllerenable on the other controller
- wait for mqtt#connected event and when handling that one, call publish commands

[bonti69]

For the moment I'll stop the experiment, because somehow controller2 locked , stays connected to HA, even I disabled the rules, and moreover the remote broker lost connection totally, even was enabled and the other one disabled. Had to remove/delete completelly the second controller(HA) to restore connection. Kind of weird. Maybe sign to stay away...

[bonti69]

I want to make a volt-amp meter with an ESP Module+ INA219 and an Oled display.
I don't need wifi after setting the device. Is there a method to disable wifi somehow, because the case of the device is full metal and the Esp module will be screened, so the wifi signal will be very low or completely unavailable ,maybe no wifi at all if I take it away . I know espeasy are rebooting randomly when wifi signal is very low.
Or maybe disable auto -reboot... or something.
I don't want the module struggling to reach wifi, just making the measurements, no ntp, no mqtt. Switch to AP Mode, if no wifi found...

[TD-er]

Not yet, but that's what I'm working on with the WiFi/network rewrite of the code in ESPEasy.

You can call the command

Code: Select all

wifimode,off

However I think it will eventually turn the WiFi on again after some time with the current code.

[bonti69]

It will be usefull to start wifi after hard reset, and an option to disable wifi automatically after a preset time, user defined.
If no wifi found after reset, device go in AP mode, in case somebody wants to change wifi network, some minutes/hours. after that,

Code: Select all

wifimode,off

Thats the scenario on my ubiquity ptp antennas, after hard reset they starts the AP mode , for setting on 2.4ghz, for some hours. The antennas are on 5Ghz, and use proprietary protocols, so normal phone cannot see their 5ghz network...

[bonti69]

However I think it will eventually turn the WiFi on again after some time with the current code.

That command it's working on the current builds? Maybe some rule to periodically isuue the command if the wifi goes back on...

But I see a feature: "Don't force /setup in AP-Mode:" maybe that's enough

Screenshot 2024-12-15 at 13-44-53 X19.png (37.11 KiB) Viewed 4566 times

[TD-er]

The command has been there for many years.
However, the current WiFi code has become such a mess, because it has to work around lots and lots of bugs and quirks of the WiFi implementation.
That's why I decided to completely rewrite the WiFi and network code, now that there is at least for ESP32 a very consistent implementation of all network related code (fairly recent code since Arduino 3.0/ESP-IDF5.1).

One of those work-arounds is to periodically reset the WiFi if no connection can be made as the WiFi radio is known to get stuck in some hard to reproduce situations.
And exactly this work-around may work against your wish to keep it off.

And that is exactly the reason why I decided to throw out all this messy code and do a rewrite.

This also involves a user-selectable state machine where you can select preferred network devices to be tried and the "all off" is one of them.
But that's not ready yet as it is taking way longer than I expected, also due to unforeseen time consuming things outside of ESPEasy.

[TD-er]

Oh and since you expect not to connect anyway, you can also lower the TX power so you don't waste as much energy and are less likely to damage the WiFi components.

Checking the checkbox not to start AP is also a good idea.

[bonti69]

Good luck, TD-er
Option to start AP-mode for some minutes if home wifi no found then shut off wifi, definetely, as an option.
Or an option to start wifi after reboot/hard reset, then wifimode-off even the home wifi is available, untill the next reboot.

[TD-er]

You can do this in rules.
For example:

Code: Select all

On system#boot do
  LoopTimerSet,1,60
endon

on Rules#Timer=1 do
  wifimode,off
endon

on WiFi#Connected do
  timerSet,1,0  // Clear timer
endon

on WiFi#disconnected do
  timerSet,1,120  // set timer to turn off WiFi again
endon

N.B. code untested, just a quick writedown.

[bonti69]

Oh and since you expect not to connect anyway, you can also lower the TX power so you don't waste as much energy and are less likely to damage the WiFi components.

Checking the checkbox not to start AP is also a good idea.

Lower the TX power not a good idea, ESP communication with the router became more unstable and eventually esp reboots itself. Had to install an additional AP nearer to my pellets boiler, because Esp reboots and shut off the power of boiler. The option to enable relay after reboot was not an option, because boiler has specific routines to start up and shutdown, time consuming, ventilation phase, ignition ... total mess

"However I think it will eventually turn the WiFi on again after some time with the current code." needs to be investigated, and why goes on ...

[TD-er]

The idea behind lowering TX power was that in a confined Faraday's cage the WiFi signal may reflect so much that it is comparable with having no antenna.
This may cause all kinds of issues and even corrupting memory or registers in the ESP.

You could also look into PoE and using Ethernet so you only have a single cable to the board and even keep connectivity.

[bonti69]

Oh, no... I want the ESP just stay quiet and do the measurements, nothing more

Or a rule to shut off wifi every minute after the first minute in AP mode