I fixed a problem with only inputs or outputs. I mage custom module for it. At least it was working on my version of board. Module and yaml config file can be found in the link below. GitHub - kecajtop/dtr0xx_io. also if possible please include this module with future release of ESPhome.
1 Like
I just flashed the latest firmware to my 4ch module and in the release notes it mentions HA integration.
So I clicked on HA Discover and it displays âadd switch/input to panelâ
Now I used this turorial Switch - Home Assistant bit it is neither displaying it as a device or entity. Any idea how to add it and/or what does the HA discovery mean?
You have to use a mqtt broker and they will auto discover in HA
It seems like the relay board has to be configuered manually with the data of the MQTT broker. MQTT broker is already running smoothly, but as you can see in the screenshot above, there is no MQTT broker address. I have to find that out and enter it here.
You have to enter your mqtt broker address and so on. It will detect it then when you use the HA Discover button.
1 Like
Many thanks, this is what I did:
Checking the config here
Checking the config here
And entering it into DTwonder page
And clicking HA discover. See line at the bottom. But I still donât see devices or entities.
Do I have to manually create the entities in configuration.yaml ? I have HA on docker and not yet managed to smbshare the config file, so I was hoping it would do some discvery.
Why are you using zigbee2mqtt? Thatâs your first error.
You have to setup âMosquitto brokerâ. Thatâs an add-on in the add-on store.
All my other devices run through Z2M and as Z2M also connects to MQTT I checked the credentials that Z2M is successfully using in order to connect to MQTT. And yes it is connecting to Mosquitto:
But I think I have found the root cause which has nothing to do with the relay board: Right now I have no ârealâ MQTT devices that connect to HA through a network port. The only connection that MQTT has is to Z2M which is running in the same docker system. So I have to set up the network connection before it has a chance to work.
You donât need Z2M for a MQTT connection between HA and dingtian.
The IP address is the local IP address of your HA Instance. Not those in docker.
To be precise: I checked Z2M because I throught I connect to MQTT the same way Z2M does - no it does NOT, as you said it connects from the OUTSIDE IP. This is what I meant with the docker address thing.
Long story short: The relay board successfully connects to MQTT and when I toggle the relays I get the message in Postman:
BUT still HA does not discover it!
=> Is there any option in HA to ârefreshâ the properties from MQTT?
SUCCESS! And yes, it was simply my fault. Without any intentional change, now I have to connect to MQTT with my localhost address, not with my Docker-IP as before. No idea when this did change. It always worked like that, now I just re-did the MQTT integration and - whoah, it is unable to connect when keeping the existing credentials! So I entered my localhost address and now it went smoothly.
So I can confirm: If the relay board is connected to MQTT and MQTT is properly configured in HA, it integrates automatically!
1 Like
So like I said 
your HA local IP address and not your docker IP address
Great it works! Only downside in my opinion is that every switch and input is a device. Iâve already contacted Stephan (owner of dingtian) about this, but they still havenât changed it.
Currently my biggest issue is that it seems like the relay board does nut support a reboot. Whenever I have to reboot the relay, maybe not intentionally, it is invisible to HA until I switch on the visibility more or less locally. I just tried it and whenever it is restarted, it is invisible to HA until I manually switch âHA Discoveryâ on. Is there any option to keep it permanent?
In addition: Does anybody know how to get a permanent update on the switch status? I mean âhow is the switch status currentlyâ which is published to dingtian/relay1234/out/relay1/ every 30sec but does not appear in HA
Change your âKeep Aliveâ in 10 seconds maybe?
I donât have this issueâs, because I use the yaml setup with mqtt.
OK so it seems like this is the only way - for a 4-way-relay, do I have to add one block for each relay? From the manual I copied the snippet that seems to be created for the old version, now it is the serial number instead of the â100â, correct?
switch:
- platform: mqtt
unique_id: dingtian100-r1
name: "Dingtian Ethernet Switch1"
state_topic: "/dingtian/relay100/out/r1"
command_topic: "/dingtian/relay100/in/r1"
availability:
- topic: "/dingtian/relay100/out/lwt_availability"
payload_available: "online"
payload_not_available: "offline"
payload_on: "ON"
payload_off: "OFF"
state_on: "ON"
state_off: "OFF"
optimistic: false
qos: 0
retain: false
- platform: mqtt
unique_id: dingtian100-r2
name: "Dingtian Ethernet Switch2"
state_topic: "/dingtian/relay100/out/r2"
command_topic: "/dingtian/relay100/in/r2"
availability:
- topic: "/dingtian/relay100/out/lwt_availability"
payload_available: "online"
payload_not_available: "offline"
payload_on: "ON"
payload_off: "OFF"
state_on: "ON"
state_off: "OFF"
optimistic: false
qos: 0
retain: false
binary_sensor:
- platform: mqtt
unique_id: dingtian100-i1
name: "Dingtian Ethernet Input1"
state_topic: "/dingtian/relay100/out/i1"
availability:
- topic: "/dingtian/relay100/out/lwt_availability"
payload_available: "online"
payload_not_available: "offline"
payload_on: "ON"
payload_off: "OFF"
qos: 0
- platform: mqtt
unique_id: dingtian100-i2
name: "Dingtian Ethernet Input2"
state_topic: "/dingtian/relay100/out/i2"
availability:
- topic: "/dingtian/relay100/out/lwt_availability"
payload_available: "online"
payload_not_available: "offline"
payload_on: "ON"
payload_off: "OFF"
qos: 0
Yeah, thatâs the old setup. One for the switch and one for the binary sensor:
mqtt:
- switch:
- name: "NAME"
state_topic: "/dingtian/relay100/out/r1"
command_topic: "/dingtian/relay100/in/r1"
availability:
- topic: "/dingtian/relay100/out/lwt_availability"
payload_available: "online"
payload_not_available: "offline"
payload_on: "ON"
payload_off: "OFF"
state_on: "ON"
state_off: "OFF"
optimistic: false
- binary_sensor:
- name: "NAME"
state_topic: "/dingtian/relay100/out/i1"
availability:
- topic: "/dingtian/relay100/out/lwt_availability"
payload_available: "online"
payload_not_available: "offline"
payload_on: "ON"
payload_off: "OFF"
qos: 0Does this also expose a âtoggleâ functionality or just a âswitch to off, regardless what it is nowâ?
Does this also expose the current state of the switch?
No, itâs an on-off switch that you can see the current state feom. Works for me.
The binary sensor is for the inputs of the dingtian.
Iâve been using them for over a year and they still work great. A little more open wouldâve been nice, but not necessary.
Two positive news:
- The developer helps directly! It is really great to be able to chat with the developer who helped me a lot.
- The board has no problems with reboot! At first I wondered why some fields are grey in the dashboard after reboot - but they all work! So of course you CAN configure it in the yaml and for some this may still be the better option - but there is no need to do so. I did some automations and then did a reboot and everything works as it should!
1 Like
Just received mine today (4ch wifi+eth) and somewhat distessed to hear esphome can only be loaded onto the dev (unlocked) model. What do I look for that might indicate if its a dev (hoping I got lucky). Was wanting to use this as a bt proxy talking to my victron charge controller. Other question is can bt be even be used on this esp32 or am I wrong assiming all esp32 has bt (probably)? Dont wana loose the ability to revert back to this fairly well built ui in case I want to. The relays and injection case was only bonus, iâll use other esp with eth device if need be (less wifi devices). Nice unit though, might throw it in my smartvan haha. Still interested though, if the bootloader can be unlocked or vanilla firmware modified as desired.