Hardware suggestions with limited Ethernet link

[thalesmaoa]

Hello everyone,

I'm in need of some help to solve my problem with espeasy. I have a container with a poor WiFi connection, and unfortunately, I cannot improve it. However, I do have an Ethernet cable that I'm using to connect to espeasy.

The issue is that I'm running out of pins to add more sensors to my link, and I can't add an Ethernet switch in this place. So, I'm looking for some alternatives to help me get the most out of espeasy.

Here are the options I've considered:

Add I2C sensors: This seems like a simple and fast solution, and some sensors are already implemented in espeasy. However, not every sensor allows for address configuration, and I may need to write a lot of plugins for some sensors.

Use a promini extender: This could solve the problem for digital and analog sensors, but SPI sensors require specific firmware programming, which may not be ideal for the purpose of espeasy.

Try to use another esp32 and add it to the network: This is where I need the most help. I know it's possible to make them talk to each other, but I'm not sure how to do it. I know I can create an AP Mode and make the other esp32 connect to it, but I won't be able to access it from the Ethernet cable. I'm also not sure about P2P, as it only works with UDP connected devices, and I have no clue about ESP NOW. Wired connection is preferable as well

If anyone has any suggestions or ideas on how to proceed, please let me know. Any help would be greatly appreciated. Thank you in advance.

[Ath]

Can you provide an overview of the sensors and devices you need to use at that location? That part isn't clear to me yet.

[TD-er]

One option could be to add a Mikrotik mAP lite
This way you can add WiFi on location.
These can also be configured to act like a bridge, so you're still in the same subnet.

To overcome the I2C address limits, you could consider using an I2C multiplexer: https://espeasy.readthedocs.io/en/lates ... ultiplexer

There is an open pull request (still work-in-progress) to use an ESPEasy p2p layer via ESP-NOW: https://github.com/letscontrolit/ESPEasy/pull/3301

Right now it can only sync system time among nodes and send MQTT from within the mesh to the gateway node. (a node connected to a MQTT broker and with ESPEasy-NOW mesh enabled).

p2p commands from any node to any other node is not yet working as I'm working on that.

[thalesmaoa]

Hi @Ath, appreciate your help.

I need to connect 6 thermocouples (mostly SPI IC), 2 load cells (4-20mA with shunt and I2C ADC), 10 relays, and 5 digital input DI. I'm looking to replace an old industrial device that uses ethernet/ip and has a gateway with modules connected to it for thermocouples, DIO, analog input, and output. The devices use their own bus, but I was thinking about using I2C or ESP-NOW.

If I need to expand in the future, I want it to be easy to do so. I've attached an image for reference.



Hey @TD-er,

Thanks for your suggestion about using Mikrotik, I'll definitely check it out. So far, I've been using ESPEasy since the mega-20200721 build for Sonoff devices to control lights. I've also used it for non-critical industrial devices like thermocouples for up to 30 days. But now, I want to control some processes in an industrial plant and I'm wondering if you have any advice on how to do that.

Also, thanks for mentioning ESP-NOW, I'll do some research on it and see if there's anything I can contribute.

Thanks again for your help!

[TD-er]

ESP-NOW does seem very nice when purely looking at the (very limited) documentation for it.
The main selling points are its extreme low latency. (sub-msec is possible)
However there are some major drawbacks:

- Extremely limited documentation describing the possible issues
- You need to know the MAC address of the device receiving the messages (AP/STA interface use different MAC for obvious reasons)
- Interoperability between ESP32/ESP8266 is not always working
- "Always on" device should use AP mode -> max energy consumption
- STA mode cannot set channel, only AP mode, which makes it tricky to implement a "gateway" from ESP-NOW to WiFi.
- You can only send upto 200-ish bytes per packet
- "Broadcast" only can send to known "peers", but you can only have upto 6/10/20 peers (depending on some factors like encryption)
- Actual latency depends on reception quality as the peer must give an "ack". The ESP-NOW layer does retry at lower data rate without the user knowing.

And some more limitations.

So yes, it it is a nice protocol, but you really need to dive deep into its (undocumented) internals to make use of it.