I have configured them as slave 1,2,3 and 4. And then I have added a section for each one of them in sensors.yaml. If I do it like that I get that same warning. For each of the sdm120s. But, if I comment out the section for slave 2, 3 and 4 I don’t get any warnings…
Tried the suggestions in this thread:
But it’s not working for me. I’m using a Modbus to USB dongle.
Perhaps it will work for you.
I am using a few SDM120s and I get errors from them as soon as I have more than one slave. Currently I am not sure if it is the SDM120s that are causing this or if it is home assistant…
There is a youtube video that describes how to setup these: https://www.youtube.com/watch?v=yBtqKSWDn1Q&t=1173s
But you probably know this already since you have changed to 9600 bps… If not, perhaps you can have a look at this video. He uses modbus poll and another tool that I don’t remember the name of.
I think both of these tools should be able to poll data from multiple modbus slaves. I would like to set it up like that and see if I can read all the registers from all the slaves with that tool. That way I might be able to figure out if this issue is caused by home assistant or by the slaves.
My other plan is to use a modbus gateway module, such as ADM-5850G, that converts from modbus serial interface to modbus TCP. I have bought one but not had time to test it out yet.
You might be having the same issue as I am, with the “No response from modbus slave” errors.
I created an issues report for it, but it doesn’t seem to have gotten much attention yet.
1 Like
Yes, that does indeed look very similar to the issue described by myself and PierreScerri.
Do you happen to know if this error is likely to go away if I use a serial to tcp modbus converter like the ADM-5850G or will I just be wasting my time trying that approach? Also, is there anything I can do to help out with getting this issue resolved?
Thanks
I’m not 100% sure. I would expect yes, it would, because the converter will be dealing with the RS485 interface and HA will only need to talk to a single Modbus TCP/IP device, which I haven’t seen any specific bug reports about. I just ordered one myself (this one) a few days ago to test that theory.
I would expect that any device designed to talk proper RS485 MB RTU would have no problems, because the protocol is pretty darn simple, comparatively. I also didn’t have any issue reading my modbus devices with industry standard tools, only the HA component seems to be the one failing here.
One caveat though, is that you will ONLY be able to read from that one device; at least that’s what I gather from this feature request. So you would not be able to have any more modbus TCP/IP devices that you want to read, and all other RS485 devices will have to all be connected to your one converter
Maybe comment in the github issue that you are also having this problem? Unless you’re a programmer yourself, we just need to get someone who is to look at it, as far as I can tell.
I’m not 100% sure. I would expect yes, it would, because the converter will be dealing with the RS485 interface and HA will only need to talk to a single Modbus TCP/IP device, which I haven’t seen any specific bug reports about. I just ordered one myself (this one ) a few days ago to test that theory.
Ok, I have now installed the RTU to TCP converter and there are no more errors.I do get a bunch of warnings instead:
2018-11-13 09:38:35 WARNING (MainThread) [homeassistant.components.sensor] Updating modbus1 sensor took longer than the scheduled update interval 0:00:01
2018-11-13 09:38:39 WARNING (MainThread) [homeassistant.components.sensor] Updating modbus1 sensor took longer than the scheduled update interval 0:00:01
2018-11-13 09:38:40 WARNING (MainThread) [homeassistant.components.sensor] Updating modbus1 sensor took longer than the scheduled update interval 0:00:01
2018-11-13 09:38:42 WARNING (MainThread) [homeassistant.components.sensor] Updating modbus1 sensor took longer than the scheduled update interval 0:00:01
2018-11-13 09:38:43 WARNING (MainThread) [homeassistant.components.sensor] Updating modbus1 sensor took longer than the scheduled update interval 0:00:01
2018-11-13 09:38:45 WARNING (MainThread) [homeassistant.components.sensor] Updating modbus1 sensor took longer than the scheduled update interval 0:00:01
But I have not managed to find anything wrong with the readings. I cranked up the scan_interval to 1 time per second and so far everything is ok.
One caveat though, is that you will ONLY be able to read from that one device; at least that’s what I gather from this feature request . So you would not be able to have any more modbus TCP/IP devices that you want to read, and all other RS485 devices will have to all be connected to your one converter
I am not so sure about that, I followed the instructions in the same feature request. and I now have two modbus TCP slaves talking to home assistant, I already have a PLC from earlier and now my new modbus converter which is using the custom modbus1.py, so far it seems to be working fine.
Maybe comment in the github issue that you are also having this problem? Unless you’re a programmer yourself, we just need to get someone who is to look at it, as far as I can tell.
Yeah, I will make an account in GitHub and comment.
so any progress with this matter?
Which matter are you referring to?
Modbus rtu performance…
ok…No, not for me… I have given up on this. I first converted to modbus TCP and that did solve a lot of the issues but I still had a bunch of warnings and it was not fast enough so I am now trying another approach:
I installed the hassio “node red” add on with “node-red-contrib-modbus” package. I can then poll modbus from node red and send to home assistant as MQTT sensor.
I just got it to work now, it’s not that hard to setup, but I haven’t transferred all the sensors over to node red. So far it seems to work fine, I can setup my modbus push buttons to be polled every 200 ms from node red and then just publish to a MQTT topic when state changes.
Can you please share settings??
So you mean mqtt server is talking to the modbus and answer home assistance?
And you defined mqtt switch?
Hi, yeah something like that. I don’t really know much about MQTT so I am trying to learn it now. I haven’t gotten to switches yet, so far I have received a reading from a temperature sensor using modbus flex getter in node red. I have then published that to my mosquitto MQTT broker (or server, I don’t know the terminology here). I have then created a MQTT sensor in home assistant which is receiving data from node red. This is working. I am going to try to create a switch next and see how that works. I don’t have anything useful to share at the moment, I suggest you have a look at this video first… they are using modbus read instead of flex getter, I am not sure what the difference is… I read somewhere that modbus flex getter is more stable but it is no problem to change later if you have issues.
Are you running hassio? If so, you can just go to the add on shop and add node red from the community add ons. And in the config you have to add the modbus package (“node-red-contrib-modbus”), like this:
“npm_packages”: [
“node-red-contrib-modbus”
],
If you can get your modbus sensors to update in node red that is about 50 % of the battle. The next step is to publish to home assistant, I might be able to help out with that once I have figured it out myself. And also, I have no guarantee that this will work, I just really hope that it will.
Anyone manage to resolve modbus response i am getting lots of errors…
About
Path to configuration.yaml: /home/homeassistant/.homeassistant
81 Loaded Components
Developed by a bunch of awesome people.
Published under the Apache 2.0 license
Source: server — frontend-ui
Built using Python 3, Polymer, Icons by Google and MaterialDesignIcons.com.
Frontend JavaScript version: latest
>> Set lovelace as default page on this device <<
No response from modbus slave 1, register 1
1:07 PM components/sensor/modbus.py (ERROR)
Updating modbus sensor took longer than the scheduled update interval 0:00:01
1:06 PM helpers/entity_platform.py (WARNING)
Updating modbus sensor took longer than the scheduled update interval 0:00:01
1:06 PM helpers/entity_platform.py (WARNING)
No response from modbus slave 10 coil 4
1:06 PM components/switch/modbus.py (ERROR)
Updating modbus switch took longer than the scheduled update interval 0:00:30
1:06 PM helpers/entity_platform.py (WARNING)
Updating modbus sensor took longer than the scheduled update interval 0:00:01
1:06 PM helpers/entity_platform.py (WARNING)
Updating modbus sensor took longer than the scheduled update interval 0:00:01
1:06 PM helpers/entity_platform.py (WARNING)
No response from modbus slave 1, register 10
1:06 PM components/sensor/modbus.py (ERROR)
Someone must know about this matter no??..
There are still at least 2 issues open on github:
As for progress, there’s been none as far as I know in terms of fixing the component’s timing or allowing configurable delays between commands.
The only progress I’m aware of is a work-in-progress pull request from 12 days ago to allow multiple hubs:
Personally, I don’t have any hope that there will be a timely resolution for the issue (from the group of volunteer programmers we have) so I got a modbus RTU->TCP/IP converter a month or two ago, and the Modbus TCP/IP component seems to work fine. Or, as another user pointed out, you could try reading it in through NodeRed i suppose…
Hi
I have the ‘No response from Modbus Slave…’ issue too. (SDM230 and SDM120 power meters connected to USB on the Pi. SDM120 gives continuous errors. SDM230 is fine)
Would you share your hardware/software setup?
Thank you.
The node red modbus implementation works fine for me, I am reading 18 push buttons, four temperature sensors and six SDM120 power meters. The push buttons are read every 200 ms and the others a bit less frequent. I am then publishing these to MQTT sensors which home assistant picks up. It is very fast and I have no errors. I am also writing coils and registers from node red to my PLC. I can recommend this approach.
Yes it seems like Node-red is the way to go.
Would you share your flow?
Thanks
Hi,
Sorry for late reply, I have been kind of busy lately… But here is a copy of one of my flows for reading data from a SDM120 power meter. I am using modbus RTU over ethernet so you will have to change that to use serial if that is what you are using.
[{“id”:“3ff3c8de.aec258”,“type”:“inject”,“z”:“151c0cc5.f5da43”,“name”:“10 sec injector”,“topic”:“”,“payload”:“”,“payloadType”:“date”,“repeat”:“10”,“crontab”:“”,“once”:false,“onceDelay”:0.1,“x”:180,“y”:180,“wires”:[[“287acab3.2791a6”]]},{“id”:“287acab3.2791a6”,“type”:“function”,“z”:“151c0cc5.f5da43”,“name”:“Read 14 registers from slave 1”,“func”:“msg.payload = {\n ‘fc’: 4, \n ‘unitid’: 1, \n ‘address’: 0 ,\n ‘quantity’: 14 \n};\nreturn msg;”,“outputs”:1,“noerr”:0,“x”:170,“y”:220,“wires”:[[“12c70b26.040335”]]},{“id”:“12c70b26.040335”,“type”:“modbus-flex-getter”,“z”:“151c0cc5.f5da43”,“name”:“voltage”,“showStatusActivities”:false,“showErrors”:false,“logIOActivities”:false,“server”:“47e72f12.61fc5”,“useIOFile”:false,“ioFile”:“”,“useIOForPayload”:false,“x”:120,“y”:280,“wires”:[[“444e31ff.fe70a”],]},{“id”:“444e31ff.fe70a”,“type”:“function”,“z”:“151c0cc5.f5da43”,“name”:“splitter”,“func”:“var x = [0,0,0,0,0,0,0,0,0,0,0,0,0,0];\nvar msg_o = [0,0,0,0,0,0,0,0,0,0,0,0,0,0];\nfor(i=0;i<14; i++){\n msg_o[i] = {payload: msg.payload[i]}; \n}\nreturn msg_o;”,“outputs”:14,“noerr”:0,“x”:410,“y”:260,“wires”:[[“fcae43a4.eaa99”],[“fcae43a4.eaa99”],,,,,[“7c2709b6.f7f588”],[“7c2709b6.f7f588”],,,,,[“e36ec90b.af1458”],[“e36ec90b.af1458”]],“outputLabels”:[“coil 100 livingroom1”,“coil 101”,“coil 102”,“coil 103”,“”,“”,“”,“”,null,null,null,null,null,null]},{“id”:“fcae43a4.eaa99”,“type”:“join”,“z”:“151c0cc5.f5da43”,“name”:“”,“mode”:“custom”,“build”:“array”,“property”:“payload”,“propertyType”:“msg”,“key”:“topic”,“joiner”:“\n”,“joinerType”:“str”,“accumulate”:false,“timeout”:“”,“count”:“2”,“reduceRight”:false,“reduceExp”:“”,“reduceInit”:“”,“reduceInitType”:“”,“reduceFixup”:“”,“x”:570,“y”:180,“wires”:[[“5bb317c7.4ac088”]]},{“id”:“7c2709b6.f7f588”,“type”:“join”,“z”:“151c0cc5.f5da43”,“name”:“”,“mode”:“custom”,“build”:“array”,“property”:“payload”,“propertyType”:“msg”,“key”:“topic”,“joiner”:“\n”,“joinerType”:“str”,“accumulate”:false,“timeout”:“”,“count”:“2”,“reduceRight”:false,“reduceExp”:“”,“reduceInit”:“”,“reduceInitType”:“”,“reduceFixup”:“”,“x”:570,“y”:240,“wires”:[[“1a80b27b.0efefe”]]},{“id”:“e36ec90b.af1458”,“type”:“join”,“z”:“151c0cc5.f5da43”,“name”:“”,“mode”:“custom”,“build”:“array”,“property”:“payload”,“propertyType”:“msg”,“key”:“topic”,“joiner”:“\n”,“joinerType”:“str”,“accumulate”:false,“timeout”:“”,“count”:“2”,“reduceRight”:false,“reduceExp”:“”,“reduceInit”:“”,“reduceInitType”:“”,“reduceFixup”:“”,“x”:570,“y”:300,“wires”:[[“5cbb0f4b.4d56d”]]},{“id”:“5bb317c7.4ac088”,“type”:“function”,“z”:“151c0cc5.f5da43”,“name”:“convert to float”,“func”:“var rawData = new ArrayBuffer(4);\nvar intView = new Uint16Array(rawData);\nvar fltView = new Float32Array(rawData);\n\n\nintView[0] = msg.payload[1]; //low\nintView[1] = msg.payload[0]; //high\n\n\nmsg.payload = parseFloat(fltView[0]).toFixed(1);\nmsg.payload = Number(msg.payload);\n\nreturn msg;”,“outputs”:1,“noerr”:0,“x”:740,“y”:180,“wires”:[[“5e854b4.e15a6b4”]]},{“id”:“1a80b27b.0efefe”,“type”:“function”,“z”:“151c0cc5.f5da43”,“name”:“convert to float”,“func”:“var rawData = new ArrayBuffer(4);\nvar intView = new Uint16Array(rawData);\nvar fltView = new Float32Array(rawData);\n\n\nintView[0] = msg.payload[1]; //low\nintView[1] = msg.payload[0]; //high\n\n\nmsg.payload = parseFloat(fltView[0]).toFixed(1);\nmsg.payload = Number(msg.payload);\n\nreturn msg;”,“outputs”:1,“noerr”:0,“x”:740,“y”:240,“wires”:[[“4782900e.d6d67”]]},{“id”:“5cbb0f4b.4d56d”,“type”:“function”,“z”:“151c0cc5.f5da43”,“name”:“convert to float”,“func”:“var rawData = new ArrayBuffer(4);\nvar intView = new Uint16Array(rawData);\nvar fltView = new Float32Array(rawData);\n\n\nintView[0] = msg.payload[1]; //low\nintView[1] = msg.payload[0]; //high\n\n\nmsg.payload = parseFloat(fltView[0]).toFixed(1);\nmsg.payload = Number(msg.payload);\n\nreturn msg;”,“outputs”:1,“noerr”:0,“x”:740,“y”:300,“wires”:[[“25e56.c9a981aa4”]]},{“id”:“5e854b4.e15a6b4”,“type”:“mqtt out”,“z”:“151c0cc5.f5da43”,“name”:“bathroom floor heating Voltage”,“topic”:“home/bathroom/floor_heating/voltage”,“qos”:“”,“retain”:“”,“broker”:“122d308f.7370af”,“x”:1010,“y”:180,“wires”:},{“id”:“4782900e.d6d67”,“type”:“mqtt out”,“z”:“151c0cc5.f5da43”,“name”:“bathroom floor heating current”,“topic”:“home/bathroom/floor_heating/current”,“qos”:“”,“retain”:“”,“broker”:“122d308f.7370af”,“x”:1010,“y”:240,“wires”:},{“id”:“25e56.c9a981aa4”,“type”:“mqtt out”,“z”:“151c0cc5.f5da43”,“name”:“bathroom floor heating power”,“topic”:“home/bathroom/floor_heating/power”,“qos”:“”,“retain”:“”,“broker”:“122d308f.7370af”,“x”:1000,“y”:300,“wires”:},{“id”:“47e72f12.61fc5”,“type”:“modbus-client”,“z”:“”,“name”:“ADM5850”,“clienttype”:“tcp”,“bufferCommands”:true,“stateLogEnabled”:false,“tcpHost”:“192.168.42.185”,“tcpPort”:“502”,“tcpType”:“DEFAULT”,“serialPort”:“/dev/ttyUSB”,“serialType”:“RTU-BUFFERD”,“serialBaudrate”:“9600”,“serialDatabits”:“8”,“serialStopbits”:“1”,“serialParity”:“none”,“serialConnectionDelay”:“100”,“unit_id”:1,“commandDelay”:1,“clientTimeout”:1000,“reconnectTimeout”:2000},{“id”:“122d308f.7370af”,“type”:“mqtt-broker”,“z”:“”,“name”:“Mosquitto”,“broker”:“192.168.42.187”,“port”:“1883”,“clientid”:“”,“usetls”:false,“compatmode”:true,“keepalive”:“60”,“cleansession”:true,“birthTopic”:“”,“birthQos”:“0”,“birthPayload”:“”,“closeTopic”:“”,“closeQos”:“0”,“closePayload”:“”,“willTopic”:“”,“willQos”:“0”,“willPayload”:“”}]
I don’t think this is the most elegant way to do things but it seems to work fine for me.