ModBusTimeout debugging

[eseglem]

I have tried as much as I can figure out, but don't seem to be having any luck with getting the modbus connection to work.

I have a CH340 based USB to RS485, and loaded up and updated a brand new raspberry pi. I see the USB show up when I plug it and and all that. After working through some permissions, I now just run into this:

Aug 08 03:32:35 raspberrypi aurora_mqtt_bridge[682]: /var/lib/gems/2.7.0/gems/rmodbus-ccutrer-2.1.0/lib/rmodbus/client/slave.rb:275:in `rescue in query': Timed out during read attempt (ModBus::Errors::ModBusTimeout)
Aug 08 03:32:35 raspberrypi aurora_mqtt_bridge[682]:         from /var/lib/gems/2.7.0/gems/rmodbus-ccutrer-2.1.0/lib/rmodbus/client/slave.rb:266:in `query'
Aug 08 03:32:35 raspberrypi aurora_mqtt_bridge[682]:         from /var/lib/gems/2.7.0/gems/waterfurnace_aurora-1.4.6/lib/aurora/modbus/slave.rb:12:in `read_multiple_holding_registers'
Aug 08 03:32:35 raspberrypi aurora_mqtt_bridge[682]:         from /var/lib/gems/2.7.0/gems/waterfurnace_aurora-1.4.6/lib/aurora/modbus/slave.rb:28:in `[]'
Aug 08 03:32:35 raspberrypi aurora_mqtt_bridge[682]:         from /var/lib/gems/2.7.0/gems/waterfurnace_aurora-1.4.6/lib/aurora/abc_client.rb:156:in `initialize'
Aug 08 03:32:35 raspberrypi aurora_mqtt_bridge[682]:         from /var/lib/gems/2.7.0/gems/waterfurnace_aurora-1.4.6/exe/aurora_mqtt_bridge:42:in `new'
Aug 08 03:32:35 raspberrypi aurora_mqtt_bridge[682]:         from /var/lib/gems/2.7.0/gems/waterfurnace_aurora-1.4.6/exe/aurora_mqtt_bridge:42:in `<top (required)>'
Aug 08 03:32:35 raspberrypi aurora_mqtt_bridge[682]:         from /usr/local/bin/aurora_mqtt_bridge:23:in `load'
Aug 08 03:32:35 raspberrypi aurora_mqtt_bridge[682]:         from /usr/local/bin/aurora_mqtt_bridge:23:in `<main>'
Aug 08 03:32:35 raspberrypi aurora_mqtt_bridge[682]: /var/lib/gems/2.7.0/gems/rmodbus-ccutrer-2.1.0/lib/rmodbus/rtu.rb:47:in `wait_readable': execution expired (ModBus::Errors::ModBusTimeout)
Aug 08 03:32:35 raspberrypi aurora_mqtt_bridge[682]:         from /var/lib/gems/2.7.0/gems/rmodbus-ccutrer-2.1.0/lib/rmodbus/rtu.rb:47:in `block in read'
Aug 08 03:32:35 raspberrypi aurora_mqtt_bridge[682]:         from /var/lib/gems/2.7.0/gems/rmodbus-ccutrer-2.1.0/lib/rmodbus/rtu.rb:43:in `loop'
Aug 08 03:32:35 raspberrypi aurora_mqtt_bridge[682]:         from /var/lib/gems/2.7.0/gems/rmodbus-ccutrer-2.1.0/lib/rmodbus/rtu.rb:43:in `read'
Aug 08 03:32:35 raspberrypi aurora_mqtt_bridge[682]:         from /var/lib/gems/2.7.0/gems/waterfurnace_aurora-1.4.6/lib/aurora/modbus/slave.rb:35:in `read_rtu_response'
Aug 08 03:32:35 raspberrypi aurora_mqtt_bridge[682]:         from /var/lib/gems/2.7.0/gems/rmodbus-ccutrer-2.1.0/lib/rmodbus/rtu_slave.rb:32:in `read_pdu'
Aug 08 03:32:35 raspberrypi aurora_mqtt_bridge[682]:         from /var/lib/gems/2.7.0/gems/rmodbus-ccutrer-2.1.0/lib/rmodbus/client/slave.rb:269:in `block in query'
Aug 08 03:32:35 raspberrypi aurora_mqtt_bridge[682]:         from /usr/lib/ruby/2.7.0/timeout.rb:105:in `timeout'
Aug 08 03:32:35 raspberrypi aurora_mqtt_bridge[682]:         from /var/lib/gems/2.7.0/gems/rmodbus-ccutrer-2.1.0/lib/rmodbus/client/slave.rb:267:in `query'
Aug 08 03:32:35 raspberrypi aurora_mqtt_bridge[682]:         from /var/lib/gems/2.7.0/gems/waterfurnace_aurora-1.4.6/lib/aurora/modbus/slave.rb:12:in `read_multiple_holding_registers'
Aug 08 03:32:35 raspberrypi aurora_mqtt_bridge[682]:         from /var/lib/gems/2.7.0/gems/waterfurnace_aurora-1.4.6/lib/aurora/modbus/slave.rb:28:in `[]'
Aug 08 03:32:35 raspberrypi aurora_mqtt_bridge[682]:         from /var/lib/gems/2.7.0/gems/waterfurnace_aurora-1.4.6/lib/aurora/abc_client.rb:156:in `initialize'
Aug 08 03:32:35 raspberrypi aurora_mqtt_bridge[682]:         from /var/lib/gems/2.7.0/gems/waterfurnace_aurora-1.4.6/exe/aurora_mqtt_bridge:42:in `new'
Aug 08 03:32:35 raspberrypi aurora_mqtt_bridge[682]:         from /var/lib/gems/2.7.0/gems/waterfurnace_aurora-1.4.6/exe/aurora_mqtt_bridge:42:in `<top (required)>'
Aug 08 03:32:35 raspberrypi aurora_mqtt_bridge[682]:         from /usr/local/bin/aurora_mqtt_bridge:23:in `load'
Aug 08 03:32:35 raspberrypi aurora_mqtt_bridge[682]:         from /usr/local/bin/aurora_mqtt_bridge:23:in `<main>'
Aug 08 03:32:35 raspberrypi systemd[1]: aurora_mqtt_bridge_USB0.service: Main process exited, code=exited, status=1/FAILURE
Aug 08 03:32:35 raspberrypi systemd[1]: aurora_mqtt_bridge_USB0.service: Failed with result 'exit-code'.
Aug 08 03:32:35 raspberrypi systemd[1]: aurora_mqtt_bridge_USB0.service: Consumed 2.896s CPU time.
Aug 08 03:32:39 raspberrypi systemd[1]: aurora_mqtt_bridge_USB0.service: Scheduled restart job, restart counter is at 1.

I tried using the built in drivers as well as https://github.com/juliagoda/CH341SER and I even tried flipping A&B just in case the board was weird or something. No luck. And tried both from the AID port on the AWL as well as directly on the unit. Always times out in all of those combos.

Symphony and AWL connect still no problems.

I am pretty much at my limit as to what to do, are there any additional debugging steps to figure this out?

[eseglem]

I got one of the 4 way splitters to see if aurora_monitor would show me anything but it still doesn't. I do see a light flashing regularly on the USB, which I assume is seeing the AWL and unit. It looks like that is the RXD light and not the TXD light, so I am not sure if something is wrong, or if its just lighting up because its receiving signal?

This one only has A, B, GND, GND, 5V on the terminals, and not separate TXD/RXD +/- and I am wondering if perhaps it is only set up for half duplex and not full duplex? I can't find anything specifically mentioned about it, but seems like something which might cause issues.

[ccutrer]

ModBus is only half duplex anyway. But I would highly recommend getting the exact USB adapter I recommend in the readme. People have had issues with other ones.

[dewoodruff]

@eseglem Did you get this figured out? I just got a Geostar Sycamore 3-ton and I can get aurora_fetch to read a whole bunch of exciting data, but running the docker container throws the same timeout error you get and aurora_monitor just sits, never returning anything to the screen. It feels like there is some kind of subscription or handshake that needs to occur so the unit starts sending data, however I'm new to this so I'm probably wrong.

I am using a Waveshare FT232RL based USB to RS485 adapter on a rpi4. It has send and receive LEDs which flash during aurora_fetch but at no other time. I am plugging into the AID pass through port on the AWL but I get the same results directly plugging in without the AWL. I won't be able to look at this again until Thursday at the earliest but then I'll start digging in.

[eseglem]

@ccutrer Yeah, I probably will. Honestly, I hadn't intended to buy a different one. I just wasn't paying enough attention. I figured it was worth asking to see if you had any thoughts before buying others. If you are interested in playing with one, with no expectation of any support or anything. I would happily send one to you. They are just going to sit and collect dust otherwise.

@dewoodruff no, I haven't really dug into it much other than trying the splitter to sniff the existing traffic. At least when using the splitter the signal LEDs flicker, but still get the timeout. So messages look like they are flowing, just not being read. I would guess its something that is fixable with a bunch of low level debugging, but not something I have the time to dedicate to. I am probably just going to buy the other USB connector and move on.

[dewoodruff]

@eseglem Does your rs485 adapter have a 120 ohm termination resistor? The Q&A on the one linked in this gitlab project indicates it does NOT. The Waveshare one I have does. So if yours does, that's a potential explanation and I'd crack mine open and pop that resistor off to see if that helps.

[eseglem]

@dewoodruff I managed to identify a SMD resistor I believe is 120 ohm, but not really sure if its the one your are referring to. It appears to be coming off pin 6 of the MAX485CSA which is "Noninverting Receiver Input and Noninverting Driver Output". Even if its the right one, its so tiny I don't know if I can get in there and get it off. Could be worth a shot though.

[ccutrer]

MAX485 is a known bad RS485 transceiver, because it requires an additional "enable" signal to be sent before sending data.

[eseglem]

@ccutrer Doh. I saw that note when I was shopping and I thought I had avoided the bad one at the time. It wasn't until I was looking under magnification this morning I even noticed the chip. And it didn't actually click that it was the bad one. So yeah, definitely buying new ones.