I think this is another issue. I would guess that the RPi also somehow tests the DTR (?) line, which is normally used to reset the arduino. Therefore you get the reset.
I thought about this a while ago. at least the ESP32 replaces the RoomClient Shield thing. But, it does not have enough pins. I need roughly 14 PWM outputs, 14 Digital INs, and 4 sets of sensor inputs for a DHT22, a light sensor and a LEDdriver output.
Surely I could just but port expanders to the ESP32 but this would also complicate things. IN addition to that, I would have to design a new shield. This would present no problem but cost time and money and wasting the perfectly good shields I have right now.
The ESP32/Arduino Mega Board would just be plugged into my RoomClient Shield and be good to go.
If you are getting connection issues then it likely is an issue with the Ethernet shield you are using, or a code problem. If you post your Arduino code it might be possible to spot the problem.
There are a lot of cheap Ethernet shields out there and lots of them have issues. The reset issue posted above is common (though I’ve never experienced it). Ideally the reset line for the Wiznet chip would be removed from the reset button and connected to an Arduino pin so you can reset the Wiznet problematically. Depending on the shield, this can be accomplished simply by removing the pushbutton and running a jumper wire from the appropriate pad to one of the Arduino pins.
Another common issue are incorrect resistors used between the connection of the PHY to the RJ45. The appropriate value is 49.9 ohms, but a lot of clones use 500 ohms! This has the effect of causing the shield to only be able to negotiate link with certain devices, or not at all, or only after multiple resets, etc. Swap the resistors with the correct value or connect another resistor in parallel:
Another great option is to swap to the EtherMega or EtherTen by Freetronics.
Yeah, the price is higher, but everything is integrated into one board, it is well designed, the designer can actually be contacted. And what’s a few more dollars for rock solid reliability?
Interesting. 510 instead of 49.9 Ohm… I will check my shields. Although I have to hit a very good day of eyesight and trebling to change the 0402’s 
I’ll digest the code down to its Ethernet/Mqtt parts and post it later.
So why does nobody trust ESPHome with a wireless connection? From my experience this is nicely stable…
I don’t think it is a ‘nobody trusts wireless’, but more of a ‘wireless is not as reliable’ thing. Esphome is quite reliable from my experiences, but the fact will always remain that my wifi devices always have more down time than ethernet. I think of how many times I have ssh’d in to my router over ethernet, to fix some issue with wifi. All these times, ethernet devices never new there was a problem. Doesn’t happen often, but the fact that this happens makes wireless at least one tick less reliable than ethernet. That isn’t even talking about interference issues that can pop up at times… what if installing a new high tech ceiling fan (or other noisy addition) creates enough local rfi to kill the wifi to an esp? That won’t ever happen with ethenet.
Bottom line, yes esphome is great for lots of things, but given an easy alternative of using ethernet (wires already there or easily installed), then that is the preferable tech to use. Really it is more like ‘use ethernet over wifi if at all possible’.
In short, wires are generally more reliable, but you are clearly having the opposite experience. This points to a hardware problem.
ok, let’s say I’d go for Ethernet. Then two possible routes are open:
Fixing the Arduino Ethernet
I’ll show the code today…
Getting an ESP32 + Ethernet up and running
@nickrout: The board look great, but it would still have too little I/O since there is no port expansion in this PCBA:
So the route here would look like this:
- Get the ESP8266 with RS232 to Arduino communcation up and running (sinceI already have this one). Yes, first implementation with WLan
- port the ESPHome code to ESP32 and Ethernet (should be done in minutes, since its just reconfiguring the ESPHome file)
- create an easy “shield” pcb to plug into the Arduino to get an reliable system
- done.
This comes now back to my initial question: Anyone knows a nice RS232 communication protocol that I can just use?
Cheers,
Christian
My humble opinion is that wireless is a great convenience, but anything that doesn’t require mobility or i snot temporary should be wired.
Again, my opinion, but when I think of permanent home automation devices I am thinking 70 years into the future (I figure by that time I’m dead and won’t care). Will WiFi be around in 15 years? Probably, but will 802.11b be now deprecated? The WiFi Consortium has always maintained backward compatibility but at the current rate of evolution, that has to change at some point. When 802.11whatever is announced in 2032 or whenever and breaks 802.11b/802.11g, it would sure be fun replacing all those light switches, outlets, etc.
Ethernet ain’t going anywhere. 100 years from now, Ethernet devices will still be able to negotiate 10MB half duplex.
It can be also a functionality to add to OpenMQTTGateway as we already support Arduino MEGA (if you fix your ethernet shield issue).
If you are interested I can help you with that. Currently, it supports reading one GPIO only and controlling one but it can be easily extended by some code.
For the anecdote, I had an Arduino UNO + an ethernet shield running OMG for several years and this was one of my most reliable home automation components.
I did a brief lock on the website and I am confused.
Here is what I think I understood: So for an ESP you have binaries, for my Arduino I would take a new project, include the OPENMQTTGateway and my cleaned up code. What would be the benefit of using OPENMQTT against a self programmed MQTT communication (If it is obvious, please excuse my ignorance 
)
So from a conservative standpoint I am totally with you. Especially since I have the cables already in place. I am/was searching for a different solution that allows me to use code from a group of capable programmers instead of my own less pair programmed and checked code.
We will see what solutions it will be, but it seems that I will stick to Ethernet…
No ignorance 
In my point of view, it works already, have all the mechanism for json publishing/receiving, discovery, system monitoring, log management …
And has been proven by users.
Sounds good, I’ll have a read tomorrow to ask more specific questions…
1 Like
Some tracks to follow:
-
ZactuatorONOFF enables to control the GPIO output by pushing a json with the gpio number and the state
-
ZsensorADC for ADC reading
-
ZsensorGPIOinput
For GPIO reading, currently support one GPIO, we should make it more modular by accepting a list of GPIO from an MQTT command with a json file like used here, if the config message is published as retained it will be stored by the broker.
We can continue the discussion here if you want
Soooo, I had a look at the code and found the following things that I would need to change/add:
- There is no support for an Ethernet shield yet, this needs to be coded
- Adding Pins seems to be limited to a few/one pin per “addon”
- My DHT sensors are supported, but with limited pins
- There is a fastled implementation (WS2812)
I found the following features:
- Autodiscovery in Home Assistant is implemented
- MQTT is implemented with functions to monitor the MQTT state and the ability to reconnect on failure
- WLan is implemented with reconnection features
Which leads to this:
- Is the code able to handle more than one pin per “Addon” (ADC,GPIO,PWM,…)
- I am able to code the Ethernet functionality. Still this code will need poishing to be able to be committed. How do you handle this over at OpenMQTTGateway?
Cheers,
Christian
PS.: Yes we should continue afterwards in the right forum
You have support for the W5100 on Arduino UNO or MEGA. For ESP32 it has to be done.
Yes
Yes
We need to modify it for that, I can help you if needed, note that PWM is in progress, I encourage you to give comments in the PR if you have.
PS.: Yes we should continue afterwards in the right forum
It will avoid some spam
Florian
Hey @CeeCee thought I’d go ahead and try to create an MQTT set up with an esp32, few headaches having no idea what I was doing but got there in the end: MQTT no callback - PubSubClient - ESP32 snippet of the Arduino code/some pointers.
had to set anonymous: from false to true in the configuration for MQTT in the supervisor menu
logins: []
anonymous: true
customize:
active: false
folder: mosquitto
certfile: fullchain.pem
keyfile: privkey.pem
require_certificate: false
added the following to the configuration.yaml:
mqtt:
broker: 192.168.0.200
username: !secret mqttUserName
password: !secret mqttPassword
light:
- platform: mqtt
name: "Office light"
state_topic: "office/light1/status"
command_topic: "office/light1/switch"
payload_on: "ON"
payload_off: "OFF"
optimistic: false
Dear @mishaVee,
thanks for your code. My problem is not to get MQTT running on my Arduino, this works happily until the reset is necessary.
I am thniking of shifting to another form of code to gain more stability. OpenMQTTGateway seems to be a good solution, since it handles all the maintenance (still connected? reconnect necessary? reconning,…) out of the box, and it integrates well into HA (so they say ).
If I go for ESPHome, I will use arduino code for the low level functions and communication to the ESP and the ESP presents Sensors to HA as usually done by ESPHome.
Hi
Have you got you system to work?
what way did you choose to go?