Access controller setting from within a rule

[SvenG]

Hi,

I have been searching quite a while but found no direct way to access controller setting from within a rule. More specifically I would like to access the IP of a MQTT controller to send it via HTTP to node-red server.

Any ideas?

[Ath]

Controller settings are not accessible from rules, at the moment. There has never been a request for that, AFAICS
The Controller settings are quite static, so that's probably why nobody thought about requesting that, but I can see why you could need that.

I'll think about how that could be implemented, as we'd probably want to do it in a way that it can provide all different settings for all controllers, without adding too much code (we're already fighting with the max. bin size for years...).

BTW, you are advised to use the ESP32 family of boards/devices, as that's the way forward when implementing new installations, the ESP8266 is no longer actively developed by Espressif (though it is still available, both as new chips and in may existing devices).
ESP32 are supported in many types by ESPEasy (the documentation is already somewhat outdated, ESP32-C2 and ESP32-C6 are available as beta).

[TD-er]

I guess this is intended as a for of provisioning?
If so then it is possible to trigger via rules to fetch settings files (and even new firmware) from a HTTP server.

Not sure if changing core settings of a controller is very practical via rules as it is a good way to get you disconnected as you probably send the events to trigger this change via the same controller you wish to change.

If it is required to toggle between controller settings, you can setup several MQTT controllers and use commands to toggle the enable/disable state of a controller using controllerenable,1 or controllerdisable,1 to toggle the state of controller #1.

[SvenG]

@Ath, I agree that controller settings are usually static and that such mechanisms as I am thinking of go far beyond everyday requirements. In view of a very heterogeneous landscape with numerous devices in the network, I would like to simplify my work as much as possible. The background to my questions is also that I want to configure the devices so that they are automatically recognised and registered by the individual servers. To this end, I'm aiming for very granular access to information via a centralised dashboard.

As far as the chip generation is concerned, the ESP32 is clearly the first choice in this area. At last, the microprocessor no longer feels like a straitjacket. Nonetheless I still use the 8266 for simple, limited tasks.

@TD-er Yes, correctly recognised. For the installations that I am planning, I need a certain degree of autonomy because I am not always on site and the internet connection frequently fails, which means that remote maintenance is not always possible. The system must therefore be able to react to both server and processor failures and other faults.

I have already seen the Settings archive functionality. That should solve some problems. Is there any documentation on the format of the settings files?

Yes, setting up several controllers is the most obvious solution.

But I have indeed already thought about changing the controller settings to a redundant IP in the event of a connection failure using a rule.

BTW, is SNMP functionality planned for the future?

Sorry for all the questions.

But nevertheless, ESPeasy is really impressive. A real Swiss army knife

[TD-er]

There is no actual planned timeline for SNMP.

The most important things for now: (not a specific order)
- Home Assistant Auto Discovery
- Wifi stability
- Matter/Thread support (IPv6 is already working)
- Power optimization (and support for power controller chips like AXP2101 as used in M5Stack CoreS3)
- User selection of specific network/WiFi mode (incl. WiFi off)
- Add support for "Safeboot" image so you can use "Max" builds on 4MB flash ESP32-variants
- Add support for 802.11ax 'sleep' mode where you can remain connected while in deep sleep.
- Add ESP-Now support
- Improve all plugins supporting Modbus-RTU to use the same non-blocking way of reading registers.
- Fix Captive Portal (during WiFi setup) for ESP32-C3/C6
- Add support for ESP32-C5 (5 GHz WiFi) ESP32-P4 (no WiFi, but quite beefy CPU with lots of GPIO) ESP32-H2 (no WiFi, low power, intended for use in Zigbee mesh)
- Add 802.15.4 support (zigbee)
- Add support for 'locked' pin state during reboot/deep sleep
- Add selection of pull-up/-down strength & "open drain" pin state
- Add hardware filtering of noise on pin state changes
- Add support for persistant storage of variables


And some more things, but these are which come up right now