ccutrer / waterfurnace_aurora

Library for communication with WaterFurnace Aurora control systems
30 stars 7 forks source link

Time out errors with 2.1.0 #56

Open kskenyon opened 8 months ago

kskenyon commented 8 months ago

I did a fresh raspberry pi OS bookworm install with the latest version of waterfurnace_aurora. I get this error and a systemd restart continuously.

aurora_mqtt_bridge[18308]: /var/lib/gems/3.1.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)

aurora_fetch ... valid > works fine and produces a nice yaml file with all the correct data.

I had this working prior to the update but I had to use Node-RED modbus to initiate a generic read every few seconds then the waterfurnace_aurora would work. Otherwise it too would time out waiting for data. It's always been pretty spotty with timeouts but now it's all the time.

Same after adding libffi per a suggestion in issues.

Did something change in the latest version that messed up the read timing in the regular app but not in aurora_fetch? Seems requiring a specific USB adapter is a bit too much. I do have the ones (2) that don't require a write before outputting data. Doesn't seem to work that way with waterfurnace_aurora.

Kevin

ccutrer commented 8 months ago

aurora_fetch and aurora_mqtt_bridge are using the exact same code to communicate with your heat pump, just providing different interfaces for you to interact with it. If you're having issues running it in systemd, your first step would be to run the bridge directly in your terminal, and not under systemd, to ensure it's not any sort of issue with running as a different user. The next step may be for me to allow the timeout to be configurable, so you can extend it to see if that helps.

The libffi comment is a red herring. As long as the gem install command works, it doesn't really matter which version you have.

As far as a specific USB adapter, that's not true. The gem should work with anything that presents itself as a serial port to the operating system, and doesn't have any weird idiosyncrasies (like requiring an additional line being asserted in order to write - any adapter based on the MAX485 chip will have this problem). The issue with the discussion on different serial chipsets ended up being a root cause of the MAX485. All that said, I simply provide a recommendation of the one I own and have tested.

Keep in mind that this is simply a hobby project to me. I don't get any compensation from it, and developed it for my own personal use. I'm of the opinion that I should share my work freely with others, so provide it here on GitHub. I try to answer questions and help people troubleshoot as I'm able, but have no obligation to do so, and definitely will not be purchasing and spending the time to test myriad RS485 adapters in order to "certify" them.

The last change to timeouts or actual communication with the unit is https://github.com/ccutrer/waterfurnace_aurora/commit/23a4bcc2ff685c9629afc8a0629f00fb1d975ba2, which was quite some time ago. I don't know what version you were previously using though. It's also possible that your unit isn't responding to a register that the mqtt bridge is assuming exists. aurora_fetch has extra logic to make smaller requests or to simply ignore individual registers that are timing out. If you can email me (cody@cutrer.us) a YAML file produced with aurora_fetch /dev/ttyHeatPump valid --yaml > myheatpump.yml, I may be able to tell if this is the problem.

kskenyon commented 8 months ago

journalctl from one cycle of systemd might be helpful. Not sure what the NoMethondError is all about.

PS: i fixed the mosquito error. Typo.

Kevin

24 18:34:58 rpi3B systemd[1]: aurora5_mqtt_bridge.service: Main process exited, code=exited, status=1/FAILURE Nov 24 18:34:58 rpi3B systemd[1]: aurora5_mqtt_bridge.service: Failed with result 'exit-code'. Nov 24 18:34:58 rpi3B systemd[1]: aurora5_mqtt_bridge.service: Consumed 1.726s CPU time. Nov 24 18:35:01 rpi3B systemd[1]: aurora5_mqtt_bridge.service: Scheduled restart job, restart counter is at 297. Nov 24 18:35:01 rpi3B systemd[1]: Stopped aurora5_mqtt_bridge.service - Aurora MQTT Bridge. Nov 24 18:35:01 rpi3B systemd[1]: aurora5_mqtt_bridge.service: Consumed 1.726s CPU time. Nov 24 18:35:01 rpi3B systemd[1]: Started aurora5_mqtt_bridge.service - Aurora MQTT Bridge. Nov 24 18:35:11 rpi3B aurora_mqtt_bridge[2623]: /var/lib/gems/3.1.0/gems/waterfurnace_aurora-1.4.8/lib/aurora/registers.rb:218:in dipswitch_settings': undefined method>>' for nil:NilClass (NoMethodError) Nov 24 18:35:11 rpi3B aurora_mqtt_bridge[2623]: accessory_relay: ACCESSORY_RELAY_SETTINGS[(value >> 3) & 0x3], Nov 24 18:35:11 rpi3B aurora_mqtt_bridge[2623]: ^^ Nov 24 18:35:11 rpi3B aurora_mqtt_bridge[2623]: from /var/lib/gems/3.1.0/gems/waterfurnace_aurora-1.4.8/lib/aurora/registers.rb:947:in call' Nov 24 18:35:11 rpi3B aurora_mqtt_bridge[2623]: from /var/lib/gems/3.1.0/gems/waterfurnace_aurora-1.4.8/lib/aurora/registers.rb:947:inblock in transform_registers' Nov 24 18:35:11 rpi3B aurora_mqtt_bridge[2623]: from /var/lib/gems/3.1.0/gems/waterfurnace_aurora-1.4.8/lib/aurora/registers.rb:943:in each' Nov 24 18:35:11 rpi3B aurora_mqtt_bridge[2623]: from /var/lib/gems/3.1.0/gems/waterfurnace_aurora-1.4.8/lib/aurora/registers.rb:943:intransform_registers' Nov 24 18:35:11 rpi3B aurora_mqtt_bridge[2623]: from /var/lib/gems/3.1.0/gems/waterfurnace_aurora-1.4.8/lib/aurora/abc_client.rb:158:in initialize' Nov 24 18:35:11 rpi3B aurora_mqtt_bridge[2623]: from /var/lib/gems/3.1.0/gems/waterfurnace_aurora-1.4.8/exe/aurora_mqtt_bridge:42:innew' Nov 24 18:35:11 rpi3B aurora_mqtt_bridge[2623]: from /var/lib/gems/3.1.0/gems/waterfurnace_aurora-1.4.8/exe/aurora_mqtt_bridge:42:in <top (required)>' Nov 24 18:35:11 rpi3B aurora_mqtt_bridge[2623]: from /usr/local/bin/aurora_mqtt_bridge:25:inload' Nov 24 18:35:11 rpi3B aurora_mqtt_bridge[2623]: from /usr/local/bin/aurora_mqtt_bridge:25:in <main>' Nov 24 18:35:11 rpi3B systemd[1]: aurora7_mqtt_bridge.service: Main process exited, code=exited, status=1/FAILURE Nov 24 18:35:11 rpi3B systemd[1]: aurora7_mqtt_bridge.service: Failed with result 'exit-code'. Nov 24 18:35:11 rpi3B systemd[1]: aurora7_mqtt_bridge.service: Consumed 1.688s CPU time. Nov 24 18:35:14 rpi3B systemd[1]: aurora7_mqtt_bridge.service: Scheduled restart job, restart counter is at 299. Nov 24 18:35:14 rpi3B systemd[1]: Stopped aurora7_mqtt_bridge.service - Aurora MQTT Bridge. Nov 24 18:35:14 rpi3B systemd[1]: aurora7_mqtt_bridge.service: Consumed 1.688s CPU time. Nov 24 18:35:15 rpi3B systemd[1]: Started aurora7_mqtt_bridge.service - Aurora MQTT Bridge. Nov 24 18:35:18 rpi3B aurora_mqtt_bridge[2631]: /var/lib/gems/3.1.0/gems/mqtt-ccutrer-1.0.3/lib/mqtt/client.rb:751:inblock in receive_connack': Connection refused: not authorised (MQTT::ProtocolException) Nov 24 18:35:18 rpi3B aurora_mqtt_bridge[2631]: from /usr/lib/ruby/3.1.0/timeout.rb:107:in block in timeout' Nov 24 18:35:18 rpi3B aurora_mqtt_bridge[2631]: from /usr/lib/ruby/3.1.0/timeout.rb:36:inblock in catch' Nov 24 18:35:18 rpi3B aurora_mqtt_bridge[2631]: from /usr/lib/ruby/3.1.0/timeout.rb:36:in catch' Nov 24 18:35:18 rpi3B aurora_mqtt_bridge[2631]: from /usr/lib/ruby/3.1.0/timeout.rb:36:incatch' Nov 24 18:35:18 rpi3B aurora_mqtt_bridge[2631]: from /usr/lib/ruby/3.1.0/timeout.rb:123:in timeout' Nov 24 18:35:18 rpi3B aurora_mqtt_bridge[2631]: from /var/lib/gems/3.1.0/gems/mqtt-ccutrer-1.0.3/lib/mqtt/client.rb:740:inreceive_connack' Nov 24 18:35:18 rpi3B aurora_mqtt_bridge[2631]: from /var/lib/gems/3.1.0/gems/mqtt-ccutrer-1.0.3/lib/mqtt/client.rb:530:in connect_internal' Nov 24 18:35:18 rpi3B aurora_mqtt_bridge[2631]: from /var/lib/gems/3.1.0/gems/mqtt-ccutrer-1.0.3/lib/mqtt/client.rb:250:inconnect' Nov 24 18:35:18 rpi3B aurora_mqtt_bridge[2631]: from /var/lib/gems/3.1.0/gems/homie-mqtt-1.6.3/lib/mqtt/homie/device.rb:36:in initialize' Nov 24 18:35:18 rpi3B aurora_mqtt_bridge[2631]: from /var/lib/gems/3.1.0/gems/waterfurnace_aurora-1.4.8/exe/aurora_mqtt_bridge:843:innew' Nov 24 18:35:18 rpi3B aurora_mqtt_bridge[2631]: from /var/lib/gems/3.1.0/gems/waterfurnace_aurora-1.4.8/exe/aurora_mqtt_bridge:843:in <top (required)>' Nov 24 18:35:18 rpi3B aurora_mqtt_bridge[2631]: from /usr/local/bin/aurora_mqtt_bridge:25:inload' Nov 24 18:35:18 rpi3B aurora_mqtt_bridge[2631]: from /usr/local/bin/aurora_mqtt_bridge:25:in `

' Nov 24 18:35:18 rpi3B systemd[1]: aurora5_mqtt_bridge.service: Main process exited, code=exited, status=1/FAILURE

On Nov 23, 2023, at 12:26 PM, Kevin Kenyon @.***> wrote:

Thanks for the detailed reply. Sorry if I sounded critical of your open source efforts. I wasn’t trying to be. I don’t do much programming any more (71 year old engineer) so I do appreciate the efforts people like you make available for my extensive tinkering. waterfurnace_aurora is very useful. I was just trying to help you make it better. I didn’t expect anything, just hopeful.

That being said. I think you may be on to something with the difference in the two code bases. I definitely tried running aurora_mqtt_bridge directly without systemd and the result was the same, just without the constant restarts.

I have a Series 5 and a Series 7. They both behave the same way even though the registers differ. I’ve attached the dumps from aurora_fetch and you can see that it seems to work perfectly. If I run it with “all’ it stops with an error at register 9999 but that might be the way it was intended to work. It runs fine on both machines with the “valid” tag. They both work OK with python3 minimalmodbus, too as long at the systemd apps are not running. I included that bit of code, too.

<2ED33117-F90E-4193-A4B2-ED50F25FC055.jpeg> <03C34FDA-3A96-4F8F-AF02-568F274E9EDD.jpeg> Thanks for any time you chose to put in on this. It seems several people are using it and timeouts are a common problem. Kevin > 23, 2023, at 9:11 AM, Cody Cutrer ***@***.***> wrote: > > > aurora_fetch and aurora_mqtt_bridge are using the exact same code to communicate with your heat pump, just providing different interfaces for you to interact with it. If you're having issues running it in systemd, your first step would be to run the bridge directly in your terminal, and not under systemd, to ensure it's not any sort of issue with running as a different user. The next step may be for me to allow the timeout to be configurable, so you can extend it to see if that helps. > > The libffi comment is a red herring. As long as the gem install command works, it doesn't really matter which version you have. > > As far as a specific USB adapter, that's not true. The gem should work with anything that presents itself as a serial port to the operating system, and doesn't have any weird idiosyncrasies (like requiring an additional line being asserted in order to write - any adapter based on the MAX485 chip will have this problem). The issue with the discussion on different serial chipsets ended up being a root cause of the MAX485. All that said, I simply provide a recommendation of the one I own and have tested. > > Keep in mind that this is simply a hobby project to me. I don't get any compensation from it, and developed it for my own personal use. I'm of the opinion that I should share my work freely with others, so provide it here on GitHub. I try to answer questions and help people troubleshoot as I'm able, but have no obligation to do so, and definitely will not be purchasing and spending the time to test myriad RS485 adapters in order to "certify" them. > > The last change to timeouts or actual communication with the unit is 23a4bcc , which was quite some time ago. I don't know what version you were previously using though. It's also possible that your unit isn't responding to a register that the mqtt bridge is assuming exists. aurora_fetch has extra logic to make smaller requests or to simply ignore individual registers that are timing out. If you can email me ***@***.*** ***@***.***>) a YAML file produced with aurora_fetch /dev/ttyHeatPump valid --yaml > myheatpump.yml, I may be able to tell if this is the problem. > > — > Reply to this email directly, view it on GitHub , or unsubscribe . > You are receiving this because you authored the thread. >
kskenyon commented 8 months ago

Interestingly, everything started working correctly after a power outage. Might have been something in the AWL’s that wasn’t right. Been running OK for two days now, no errors or missing messages. Had to convert Homie data strings to numbers to use in Grafana. I should have thought about restarting the AWL’s before. Will do that first next time.

Kevin

On Nov 24, 2023, at 6:38 PM, Kevin Kenyon @.***> wrote:

journalctl from one cycle of systemd might be helpful. Not sure what the NoMethondError is all about.

Kevin

24 18:34:58 rpi3B systemd[1]: aurora5_mqtt_bridge.service: Main process exited, code=exited, status=1/FAILURE Nov 24 18:34:58 rpi3B systemd[1]: aurora5_mqtt_bridge.service: Failed with result 'exit-code'. Nov 24 18:34:58 rpi3B systemd[1]: aurora5_mqtt_bridge.service: Consumed 1.726s CPU time. Nov 24 18:35:01 rpi3B systemd[1]: aurora5_mqtt_bridge.service: Scheduled restart job, restart counter is at 297. Nov 24 18:35:01 rpi3B systemd[1]: Stopped aurora5_mqtt_bridge.service - Aurora MQTT Bridge. Nov 24 18:35:01 rpi3B systemd[1]: aurora5_mqtt_bridge.service: Consumed 1.726s CPU time. Nov 24 18:35:01 rpi3B systemd[1]: Started aurora5_mqtt_bridge.service - Aurora MQTT Bridge. Nov 24 18:35:11 rpi3B aurora_mqtt_bridge[2623]: /var/lib/gems/3.1.0/gems/waterfurnace_aurora-1.4.8/lib/aurora/registers.rb:218:in dipswitch_settings': undefined method>>' for nil:NilClass (NoMethodError) Nov 24 18:35:11 rpi3B aurora_mqtt_bridge[2623]: accessory_relay: ACCESSORY_RELAY_SETTINGS[(value >> 3) & 0x3], Nov 24 18:35:11 rpi3B aurora_mqtt_bridge[2623]: ^^ Nov 24 18:35:11 rpi3B aurora_mqtt_bridge[2623]: from /var/lib/gems/3.1.0/gems/waterfurnace_aurora-1.4.8/lib/aurora/registers.rb:947:in call' Nov 24 18:35:11 rpi3B aurora_mqtt_bridge[2623]: from /var/lib/gems/3.1.0/gems/waterfurnace_aurora-1.4.8/lib/aurora/registers.rb:947:inblock in transform_registers' Nov 24 18:35:11 rpi3B aurora_mqtt_bridge[2623]: from /var/lib/gems/3.1.0/gems/waterfurnace_aurora-1.4.8/lib/aurora/registers.rb:943:in each' Nov 24 18:35:11 rpi3B aurora_mqtt_bridge[2623]: from /var/lib/gems/3.1.0/gems/waterfurnace_aurora-1.4.8/lib/aurora/registers.rb:943:intransform_registers' Nov 24 18:35:11 rpi3B aurora_mqtt_bridge[2623]: from /var/lib/gems/3.1.0/gems/waterfurnace_aurora-1.4.8/lib/aurora/abc_client.rb:158:in initialize' Nov 24 18:35:11 rpi3B aurora_mqtt_bridge[2623]: from /var/lib/gems/3.1.0/gems/waterfurnace_aurora-1.4.8/exe/aurora_mqtt_bridge:42:innew' Nov 24 18:35:11 rpi3B aurora_mqtt_bridge[2623]: from /var/lib/gems/3.1.0/gems/waterfurnace_aurora-1.4.8/exe/aurora_mqtt_bridge:42:in <top (required)>' Nov 24 18:35:11 rpi3B aurora_mqtt_bridge[2623]: from /usr/local/bin/aurora_mqtt_bridge:25:inload' Nov 24 18:35:11 rpi3B aurora_mqtt_bridge[2623]: from /usr/local/bin/aurora_mqtt_bridge:25:in <main>' Nov 24 18:35:11 rpi3B systemd[1]: aurora7_mqtt_bridge.service: Main process exited, code=exited, status=1/FAILURE Nov 24 18:35:11 rpi3B systemd[1]: aurora7_mqtt_bridge.service: Failed with result 'exit-code'. Nov 24 18:35:11 rpi3B systemd[1]: aurora7_mqtt_bridge.service: Consumed 1.688s CPU time. Nov 24 18:35:14 rpi3B systemd[1]: aurora7_mqtt_bridge.service: Scheduled restart job, restart counter is at 299. Nov 24 18:35:14 rpi3B systemd[1]: Stopped aurora7_mqtt_bridge.service - Aurora MQTT Bridge. Nov 24 18:35:14 rpi3B systemd[1]: aurora7_mqtt_bridge.service: Consumed 1.688s CPU time. Nov 24 18:35:15 rpi3B systemd[1]: Started aurora7_mqtt_bridge.service - Aurora MQTT Bridge. Nov 24 18:35:18 rpi3B aurora_mqtt_bridge[2631]: /var/lib/gems/3.1.0/gems/mqtt-ccutrer-1.0.3/lib/mqtt/client.rb:751:inblock in receive_connack': Connection refused: not authorised (MQTT::ProtocolException) Nov 24 18:35:18 rpi3B aurora_mqtt_bridge[2631]: from /usr/lib/ruby/3.1.0/timeout.rb:107:in block in timeout' Nov 24 18:35:18 rpi3B aurora_mqtt_bridge[2631]: from /usr/lib/ruby/3.1.0/timeout.rb:36:inblock in catch' Nov 24 18:35:18 rpi3B aurora_mqtt_bridge[2631]: from /usr/lib/ruby/3.1.0/timeout.rb:36:in catch' Nov 24 18:35:18 rpi3B aurora_mqtt_bridge[2631]: from /usr/lib/ruby/3.1.0/timeout.rb:36:incatch' Nov 24 18:35:18 rpi3B aurora_mqtt_bridge[2631]: from /usr/lib/ruby/3.1.0/timeout.rb:123:in timeout' Nov 24 18:35:18 rpi3B aurora_mqtt_bridge[2631]: from /var/lib/gems/3.1.0/gems/mqtt-ccutrer-1.0.3/lib/mqtt/client.rb:740:inreceive_connack' Nov 24 18:35:18 rpi3B aurora_mqtt_bridge[2631]: from /var/lib/gems/3.1.0/gems/mqtt-ccutrer-1.0.3/lib/mqtt/client.rb:530:in connect_internal' Nov 24 18:35:18 rpi3B aurora_mqtt_bridge[2631]: from /var/lib/gems/3.1.0/gems/mqtt-ccutrer-1.0.3/lib/mqtt/client.rb:250:inconnect' Nov 24 18:35:18 rpi3B aurora_mqtt_bridge[2631]: from /var/lib/gems/3.1.0/gems/homie-mqtt-1.6.3/lib/mqtt/homie/device.rb:36:in initialize' Nov 24 18:35:18 rpi3B aurora_mqtt_bridge[2631]: from /var/lib/gems/3.1.0/gems/waterfurnace_aurora-1.4.8/exe/aurora_mqtt_bridge:843:innew' Nov 24 18:35:18 rpi3B aurora_mqtt_bridge[2631]: from /var/lib/gems/3.1.0/gems/waterfurnace_aurora-1.4.8/exe/aurora_mqtt_bridge:843:in <top (required)>' Nov 24 18:35:18 rpi3B aurora_mqtt_bridge[2631]: from /usr/local/bin/aurora_mqtt_bridge:25:inload' Nov 24 18:35:18 rpi3B aurora_mqtt_bridge[2631]: from /usr/local/bin/aurora_mqtt_bridge:25:in `

' Nov 24 18:35:18 rpi3B systemd[1]: aurora5_mqtt_bridge.service: Main process exited, code=exited, status=1/FAILURE

On Nov 23, 2023, at 12:26 PM, Kevin Kenyon @.***> wrote:

Thanks for the detailed reply. Sorry if I sounded critical of your open source efforts. I wasn’t trying to be. I don’t do much programming any more (71 year old engineer) so I do appreciate the efforts people like you make available for my extensive tinkering. waterfurnace_aurora is very useful. I was just trying to help you make it better. I didn’t expect anything, just hopeful.

That being said. I think you may be on to something with the difference in the two code bases. I definitely tried running aurora_mqtt_bridge directly without systemd and the result was the same, just without the constant restarts.

I have a Series 5 and a Series 7. They both behave the same way even though the registers differ. I’ve attached the dumps from aurora_fetch and you can see that it seems to work perfectly. If I run it with “all’ it stops with an error at register 9999 but that might be the way it was intended to work. It runs fine on both machines with the “valid” tag. They both work OK with python3 minimalmodbus, too as long at the systemd apps are not running. I included that bit of code, too.

<2ED33117-F90E-4193-A4B2-ED50F25FC055.jpeg> <03C34FDA-3A96-4F8F-AF02-568F274E9EDD.jpeg> Thanks for any time you chose to put in on this. It seems several people are using it and timeouts are a common problem. Kevin > 23, 2023, at 9:11 AM, Cody Cutrer ***@***.***> wrote: > > > aurora_fetch and aurora_mqtt_bridge are using the exact same code to communicate with your heat pump, just providing different interfaces for you to interact with it. If you're having issues running it in systemd, your first step would be to run the bridge directly in your terminal, and not under systemd, to ensure it's not any sort of issue with running as a different user. The next step may be for me to allow the timeout to be configurable, so you can extend it to see if that helps. > > The libffi comment is a red herring. As long as the gem install command works, it doesn't really matter which version you have. > > As far as a specific USB adapter, that's not true. The gem should work with anything that presents itself as a serial port to the operating system, and doesn't have any weird idiosyncrasies (like requiring an additional line being asserted in order to write - any adapter based on the MAX485 chip will have this problem). The issue with the discussion on different serial chipsets ended up being a root cause of the MAX485. All that said, I simply provide a recommendation of the one I own and have tested. > > Keep in mind that this is simply a hobby project to me. I don't get any compensation from it, and developed it for my own personal use. I'm of the opinion that I should share my work freely with others, so provide it here on GitHub. I try to answer questions and help people troubleshoot as I'm able, but have no obligation to do so, and definitely will not be purchasing and spending the time to test myriad RS485 adapters in order to "certify" them. > > The last change to timeouts or actual communication with the unit is 23a4bcc , which was quite some time ago. I don't know what version you were previously using though. It's also possible that your unit isn't responding to a register that the mqtt bridge is assuming exists. aurora_fetch has extra logic to make smaller requests or to simply ignore individual registers that are timing out. If you can email me ***@***.*** ***@***.***>) a YAML file produced with aurora_fetch /dev/ttyHeatPump valid --yaml > myheatpump.yml, I may be able to tell if this is the problem. > > — > Reply to this email directly, view it on GitHub , or unsubscribe . > You are receiving this because you authored the thread. >
kskenyon commented 8 months ago

Spoke too soon. After a pi restart the services time out. Restarted both AWL’s and it’s still timing out. The two test python3 scripts still seem to work fine so Modbus is working. Not sure why services worked OK for a day and now they will not. Just an FYI. Some kind of a timeout problem still exists for me.

Kevin

On Nov 26, 2023, at 6:31 PM, Kevin Kenyon @.***> wrote:

Interestingly, everything started working correctly after a power outage. Might have been something in the AWL’s that wasn’t right. Been running OK for two days now, no errors or missing messages. Had to convert Homie data strings to numbers to use in Grafana. I should have thought about restarting the AWL’s before. Will do that first next time.

Kevin

On Nov 24, 2023, at 6:38 PM, Kevin Kenyon @.***> wrote:

journalctl from one cycle of systemd might be helpful. Not sure what the NoMethondError is all about.

Kevin

24 18:34:58 rpi3B systemd[1]: aurora5_mqtt_bridge.service: Main process exited, code=exited, status=1/FAILURE Nov 24 18:34:58 rpi3B systemd[1]: aurora5_mqtt_bridge.service: Failed with result 'exit-code'. Nov 24 18:34:58 rpi3B systemd[1]: aurora5_mqtt_bridge.service: Consumed 1.726s CPU time. Nov 24 18:35:01 rpi3B systemd[1]: aurora5_mqtt_bridge.service: Scheduled restart job, restart counter is at 297. Nov 24 18:35:01 rpi3B systemd[1]: Stopped aurora5_mqtt_bridge.service - Aurora MQTT Bridge. Nov 24 18:35:01 rpi3B systemd[1]: aurora5_mqtt_bridge.service: Consumed 1.726s CPU time. Nov 24 18:35:01 rpi3B systemd[1]: Started aurora5_mqtt_bridge.service - Aurora MQTT Bridge. Nov 24 18:35:11 rpi3B aurora_mqtt_bridge[2623]: /var/lib/gems/3.1.0/gems/waterfurnace_aurora-1.4.8/lib/aurora/registers.rb:218:in dipswitch_settings': undefined method>>' for nil:NilClass (NoMethodError) Nov 24 18:35:11 rpi3B aurora_mqtt_bridge[2623]: accessory_relay: ACCESSORY_RELAY_SETTINGS[(value >> 3) & 0x3], Nov 24 18:35:11 rpi3B aurora_mqtt_bridge[2623]: ^^ Nov 24 18:35:11 rpi3B aurora_mqtt_bridge[2623]: from /var/lib/gems/3.1.0/gems/waterfurnace_aurora-1.4.8/lib/aurora/registers.rb:947:in call' Nov 24 18:35:11 rpi3B aurora_mqtt_bridge[2623]: from /var/lib/gems/3.1.0/gems/waterfurnace_aurora-1.4.8/lib/aurora/registers.rb:947:inblock in transform_registers' Nov 24 18:35:11 rpi3B aurora_mqtt_bridge[2623]: from /var/lib/gems/3.1.0/gems/waterfurnace_aurora-1.4.8/lib/aurora/registers.rb:943:in each' Nov 24 18:35:11 rpi3B aurora_mqtt_bridge[2623]: from /var/lib/gems/3.1.0/gems/waterfurnace_aurora-1.4.8/lib/aurora/registers.rb:943:intransform_registers' Nov 24 18:35:11 rpi3B aurora_mqtt_bridge[2623]: from /var/lib/gems/3.1.0/gems/waterfurnace_aurora-1.4.8/lib/aurora/abc_client.rb:158:in initialize' Nov 24 18:35:11 rpi3B aurora_mqtt_bridge[2623]: from /var/lib/gems/3.1.0/gems/waterfurnace_aurora-1.4.8/exe/aurora_mqtt_bridge:42:innew' Nov 24 18:35:11 rpi3B aurora_mqtt_bridge[2623]: from /var/lib/gems/3.1.0/gems/waterfurnace_aurora-1.4.8/exe/aurora_mqtt_bridge:42:in <top (required)>' Nov 24 18:35:11 rpi3B aurora_mqtt_bridge[2623]: from /usr/local/bin/aurora_mqtt_bridge:25:inload' Nov 24 18:35:11 rpi3B aurora_mqtt_bridge[2623]: from /usr/local/bin/aurora_mqtt_bridge:25:in <main>' Nov 24 18:35:11 rpi3B systemd[1]: aurora7_mqtt_bridge.service: Main process exited, code=exited, status=1/FAILURE Nov 24 18:35:11 rpi3B systemd[1]: aurora7_mqtt_bridge.service: Failed with result 'exit-code'. Nov 24 18:35:11 rpi3B systemd[1]: aurora7_mqtt_bridge.service: Consumed 1.688s CPU time. Nov 24 18:35:14 rpi3B systemd[1]: aurora7_mqtt_bridge.service: Scheduled restart job, restart counter is at 299. Nov 24 18:35:14 rpi3B systemd[1]: Stopped aurora7_mqtt_bridge.service - Aurora MQTT Bridge. Nov 24 18:35:14 rpi3B systemd[1]: aurora7_mqtt_bridge.service: Consumed 1.688s CPU time. Nov 24 18:35:15 rpi3B systemd[1]: Started aurora7_mqtt_bridge.service - Aurora MQTT Bridge. Nov 24 18:35:18 rpi3B aurora_mqtt_bridge[2631]: /var/lib/gems/3.1.0/gems/mqtt-ccutrer-1.0.3/lib/mqtt/client.rb:751:inblock in receive_connack': Connection refused: not authorised (MQTT::ProtocolException) Nov 24 18:35:18 rpi3B aurora_mqtt_bridge[2631]: from /usr/lib/ruby/3.1.0/timeout.rb:107:in block in timeout' Nov 24 18:35:18 rpi3B aurora_mqtt_bridge[2631]: from /usr/lib/ruby/3.1.0/timeout.rb:36:inblock in catch' Nov 24 18:35:18 rpi3B aurora_mqtt_bridge[2631]: from /usr/lib/ruby/3.1.0/timeout.rb:36:in catch' Nov 24 18:35:18 rpi3B aurora_mqtt_bridge[2631]: from /usr/lib/ruby/3.1.0/timeout.rb:36:incatch' Nov 24 18:35:18 rpi3B aurora_mqtt_bridge[2631]: from /usr/lib/ruby/3.1.0/timeout.rb:123:in timeout' Nov 24 18:35:18 rpi3B aurora_mqtt_bridge[2631]: from /var/lib/gems/3.1.0/gems/mqtt-ccutrer-1.0.3/lib/mqtt/client.rb:740:inreceive_connack' Nov 24 18:35:18 rpi3B aurora_mqtt_bridge[2631]: from /var/lib/gems/3.1.0/gems/mqtt-ccutrer-1.0.3/lib/mqtt/client.rb:530:in connect_internal' Nov 24 18:35:18 rpi3B aurora_mqtt_bridge[2631]: from /var/lib/gems/3.1.0/gems/mqtt-ccutrer-1.0.3/lib/mqtt/client.rb:250:inconnect' Nov 24 18:35:18 rpi3B aurora_mqtt_bridge[2631]: from /var/lib/gems/3.1.0/gems/homie-mqtt-1.6.3/lib/mqtt/homie/device.rb:36:in initialize' Nov 24 18:35:18 rpi3B aurora_mqtt_bridge[2631]: from /var/lib/gems/3.1.0/gems/waterfurnace_aurora-1.4.8/exe/aurora_mqtt_bridge:843:innew' Nov 24 18:35:18 rpi3B aurora_mqtt_bridge[2631]: from /var/lib/gems/3.1.0/gems/waterfurnace_aurora-1.4.8/exe/aurora_mqtt_bridge:843:in <top (required)>' Nov 24 18:35:18 rpi3B aurora_mqtt_bridge[2631]: from /usr/local/bin/aurora_mqtt_bridge:25:inload' Nov 24 18:35:18 rpi3B aurora_mqtt_bridge[2631]: from /usr/local/bin/aurora_mqtt_bridge:25:in `

' Nov 24 18:35:18 rpi3B systemd[1]: aurora5_mqtt_bridge.service: Main process exited, code=exited, status=1/FAILURE

On Nov 23, 2023, at 12:26 PM, Kevin Kenyon @.***> wrote:

Thanks for the detailed reply. Sorry if I sounded critical of your open source efforts. I wasn’t trying to be. I don’t do much programming any more (71 year old engineer) so I do appreciate the efforts people like you make available for my extensive tinkering. waterfurnace_aurora is very useful. I was just trying to help you make it better. I didn’t expect anything, just hopeful.

That being said. I think you may be on to something with the difference in the two code bases. I definitely tried running aurora_mqtt_bridge directly without systemd and the result was the same, just without the constant restarts.

I have a Series 5 and a Series 7. They both behave the same way even though the registers differ. I’ve attached the dumps from aurora_fetch and you can see that it seems to work perfectly. If I run it with “all’ it stops with an error at register 9999 but that might be the way it was intended to work. It runs fine on both machines with the “valid” tag. They both work OK with python3 minimalmodbus, too as long at the systemd apps are not running. I included that bit of code, too.

<2ED33117-F90E-4193-A4B2-ED50F25FC055.jpeg> <03C34FDA-3A96-4F8F-AF02-568F274E9EDD.jpeg> Thanks for any time you chose to put in on this. It seems several people are using it and timeouts are a common problem. Kevin > 23, 2023, at 9:11 AM, Cody Cutrer ***@***.***> wrote: > > > aurora_fetch and aurora_mqtt_bridge are using the exact same code to communicate with your heat pump, just providing different interfaces for you to interact with it. If you're having issues running it in systemd, your first step would be to run the bridge directly in your terminal, and not under systemd, to ensure it's not any sort of issue with running as a different user. The next step may be for me to allow the timeout to be configurable, so you can extend it to see if that helps. > > The libffi comment is a red herring. As long as the gem install command works, it doesn't really matter which version you have. > > As far as a specific USB adapter, that's not true. The gem should work with anything that presents itself as a serial port to the operating system, and doesn't have any weird idiosyncrasies (like requiring an additional line being asserted in order to write - any adapter based on the MAX485 chip will have this problem). The issue with the discussion on different serial chipsets ended up being a root cause of the MAX485. All that said, I simply provide a recommendation of the one I own and have tested. > > Keep in mind that this is simply a hobby project to me. I don't get any compensation from it, and developed it for my own personal use. I'm of the opinion that I should share my work freely with others, so provide it here on GitHub. I try to answer questions and help people troubleshoot as I'm able, but have no obligation to do so, and definitely will not be purchasing and spending the time to test myriad RS485 adapters in order to "certify" them. > > The last change to timeouts or actual communication with the unit is 23a4bcc , which was quite some time ago. I don't know what version you were previously using though. It's also possible that your unit isn't responding to a register that the mqtt bridge is assuming exists. aurora_fetch has extra logic to make smaller requests or to simply ignore individual registers that are timing out. If you can email me ***@***.*** ***@***.***>) a YAML file produced with aurora_fetch /dev/ttyHeatPump valid --yaml > myheatpump.yml, I may be able to tell if this is the problem. > > — > Reply to this email directly, view it on GitHub , or unsubscribe . > You are receiving this because you authored the thread. >
kskenyon commented 8 months ago

After a restart I get the timeout errors as long as I don’t do anything. If I hammer modbus with the miminalmodbus code for a few minutes it tends to take off and work as long as the power stays on. It takes a while to get them going after a power outage and I have to intervene. Time for a UPS I guess.

Kevin

On Nov 27, 2023, at 4:52 PM, Kevin Kenyon @.***> wrote:

Spoke too soon. After a pi restart the services time out. Restarted both AWL’s and it’s still timing out. The two test python3 scripts still seem to work fine so Modbus is working. Not sure why services worked OK for a day and now they will not. Just an FYI. Some kind of a timeout problem still exists for me.

Kevin

On Nov 26, 2023, at 6:31 PM, Kevin Kenyon @.***> wrote:

Interestingly, everything started working correctly after a power outage. Might have been something in the AWL’s that wasn’t right. Been running OK for two days now, no errors or missing messages. Had to convert Homie data strings to numbers to use in Grafana. I should have thought about restarting the AWL’s before. Will do that first next time.

Kevin

On Nov 24, 2023, at 6:38 PM, Kevin Kenyon @.***> wrote:

journalctl from one cycle of systemd might be helpful. Not sure what the NoMethondError is all about.

Kevin

24 18:34:58 rpi3B systemd[1]: aurora5_mqtt_bridge.service: Main process exited, code=exited, status=1/FAILURE Nov 24 18:34:58 rpi3B systemd[1]: aurora5_mqtt_bridge.service: Failed with result 'exit-code'. Nov 24 18:34:58 rpi3B systemd[1]: aurora5_mqtt_bridge.service: Consumed 1.726s CPU time. Nov 24 18:35:01 rpi3B systemd[1]: aurora5_mqtt_bridge.service: Scheduled restart job, restart counter is at 297. Nov 24 18:35:01 rpi3B systemd[1]: Stopped aurora5_mqtt_bridge.service - Aurora MQTT Bridge. Nov 24 18:35:01 rpi3B systemd[1]: aurora5_mqtt_bridge.service: Consumed 1.726s CPU time. Nov 24 18:35:01 rpi3B systemd[1]: Started aurora5_mqtt_bridge.service - Aurora MQTT Bridge. Nov 24 18:35:11 rpi3B aurora_mqtt_bridge[2623]: /var/lib/gems/3.1.0/gems/waterfurnace_aurora-1.4.8/lib/aurora/registers.rb:218:in dipswitch_settings': undefined method>>' for nil:NilClass (NoMethodError) Nov 24 18:35:11 rpi3B aurora_mqtt_bridge[2623]: accessory_relay: ACCESSORY_RELAY_SETTINGS[(value >> 3) & 0x3], Nov 24 18:35:11 rpi3B aurora_mqtt_bridge[2623]: ^^ Nov 24 18:35:11 rpi3B aurora_mqtt_bridge[2623]: from /var/lib/gems/3.1.0/gems/waterfurnace_aurora-1.4.8/lib/aurora/registers.rb:947:in call' Nov 24 18:35:11 rpi3B aurora_mqtt_bridge[2623]: from /var/lib/gems/3.1.0/gems/waterfurnace_aurora-1.4.8/lib/aurora/registers.rb:947:inblock in transform_registers' Nov 24 18:35:11 rpi3B aurora_mqtt_bridge[2623]: from /var/lib/gems/3.1.0/gems/waterfurnace_aurora-1.4.8/lib/aurora/registers.rb:943:in each' Nov 24 18:35:11 rpi3B aurora_mqtt_bridge[2623]: from /var/lib/gems/3.1.0/gems/waterfurnace_aurora-1.4.8/lib/aurora/registers.rb:943:intransform_registers' Nov 24 18:35:11 rpi3B aurora_mqtt_bridge[2623]: from /var/lib/gems/3.1.0/gems/waterfurnace_aurora-1.4.8/lib/aurora/abc_client.rb:158:in initialize' Nov 24 18:35:11 rpi3B aurora_mqtt_bridge[2623]: from /var/lib/gems/3.1.0/gems/waterfurnace_aurora-1.4.8/exe/aurora_mqtt_bridge:42:innew' Nov 24 18:35:11 rpi3B aurora_mqtt_bridge[2623]: from /var/lib/gems/3.1.0/gems/waterfurnace_aurora-1.4.8/exe/aurora_mqtt_bridge:42:in <top (required)>' Nov 24 18:35:11 rpi3B aurora_mqtt_bridge[2623]: from /usr/local/bin/aurora_mqtt_bridge:25:inload' Nov 24 18:35:11 rpi3B aurora_mqtt_bridge[2623]: from /usr/local/bin/aurora_mqtt_bridge:25:in <main>' Nov 24 18:35:11 rpi3B systemd[1]: aurora7_mqtt_bridge.service: Main process exited, code=exited, status=1/FAILURE Nov 24 18:35:11 rpi3B systemd[1]: aurora7_mqtt_bridge.service: Failed with result 'exit-code'. Nov 24 18:35:11 rpi3B systemd[1]: aurora7_mqtt_bridge.service: Consumed 1.688s CPU time. Nov 24 18:35:14 rpi3B systemd[1]: aurora7_mqtt_bridge.service: Scheduled restart job, restart counter is at 299. Nov 24 18:35:14 rpi3B systemd[1]: Stopped aurora7_mqtt_bridge.service - Aurora MQTT Bridge. Nov 24 18:35:14 rpi3B systemd[1]: aurora7_mqtt_bridge.service: Consumed 1.688s CPU time. Nov 24 18:35:15 rpi3B systemd[1]: Started aurora7_mqtt_bridge.service - Aurora MQTT Bridge. Nov 24 18:35:18 rpi3B aurora_mqtt_bridge[2631]: /var/lib/gems/3.1.0/gems/mqtt-ccutrer-1.0.3/lib/mqtt/client.rb:751:inblock in receive_connack': Connection refused: not authorised (MQTT::ProtocolException) Nov 24 18:35:18 rpi3B aurora_mqtt_bridge[2631]: from /usr/lib/ruby/3.1.0/timeout.rb:107:in block in timeout' Nov 24 18:35:18 rpi3B aurora_mqtt_bridge[2631]: from /usr/lib/ruby/3.1.0/timeout.rb:36:inblock in catch' Nov 24 18:35:18 rpi3B aurora_mqtt_bridge[2631]: from /usr/lib/ruby/3.1.0/timeout.rb:36:in catch' Nov 24 18:35:18 rpi3B aurora_mqtt_bridge[2631]: from /usr/lib/ruby/3.1.0/timeout.rb:36:incatch' Nov 24 18:35:18 rpi3B aurora_mqtt_bridge[2631]: from /usr/lib/ruby/3.1.0/timeout.rb:123:in timeout' Nov 24 18:35:18 rpi3B aurora_mqtt_bridge[2631]: from /var/lib/gems/3.1.0/gems/mqtt-ccutrer-1.0.3/lib/mqtt/client.rb:740:inreceive_connack' Nov 24 18:35:18 rpi3B aurora_mqtt_bridge[2631]: from /var/lib/gems/3.1.0/gems/mqtt-ccutrer-1.0.3/lib/mqtt/client.rb:530:in connect_internal' Nov 24 18:35:18 rpi3B aurora_mqtt_bridge[2631]: from /var/lib/gems/3.1.0/gems/mqtt-ccutrer-1.0.3/lib/mqtt/client.rb:250:inconnect' Nov 24 18:35:18 rpi3B aurora_mqtt_bridge[2631]: from /var/lib/gems/3.1.0/gems/homie-mqtt-1.6.3/lib/mqtt/homie/device.rb:36:in initialize' Nov 24 18:35:18 rpi3B aurora_mqtt_bridge[2631]: from /var/lib/gems/3.1.0/gems/waterfurnace_aurora-1.4.8/exe/aurora_mqtt_bridge:843:innew' Nov 24 18:35:18 rpi3B aurora_mqtt_bridge[2631]: from /var/lib/gems/3.1.0/gems/waterfurnace_aurora-1.4.8/exe/aurora_mqtt_bridge:843:in <top (required)>' Nov 24 18:35:18 rpi3B aurora_mqtt_bridge[2631]: from /usr/local/bin/aurora_mqtt_bridge:25:inload' Nov 24 18:35:18 rpi3B aurora_mqtt_bridge[2631]: from /usr/local/bin/aurora_mqtt_bridge:25:in `

' Nov 24 18:35:18 rpi3B systemd[1]: aurora5_mqtt_bridge.service: Main process exited, code=exited, status=1/FAILURE

On Nov 23, 2023, at 12:26 PM, Kevin Kenyon @.***> wrote:

Thanks for the detailed reply. Sorry if I sounded critical of your open source efforts. I wasn’t trying to be. I don’t do much programming any more (71 year old engineer) so I do appreciate the efforts people like you make available for my extensive tinkering. waterfurnace_aurora is very useful. I was just trying to help you make it better. I didn’t expect anything, just hopeful.

That being said. I think you may be on to something with the difference in the two code bases. I definitely tried running aurora_mqtt_bridge directly without systemd and the result was the same, just without the constant restarts.

I have a Series 5 and a Series 7. They both behave the same way even though the registers differ. I’ve attached the dumps from aurora_fetch and you can see that it seems to work perfectly. If I run it with “all’ it stops with an error at register 9999 but that might be the way it was intended to work. It runs fine on both machines with the “valid” tag. They both work OK with python3 minimalmodbus, too as long at the systemd apps are not running. I included that bit of code, too.

<2ED33117-F90E-4193-A4B2-ED50F25FC055.jpeg> <03C34FDA-3A96-4F8F-AF02-568F274E9EDD.jpeg> Thanks for any time you chose to put in on this. It seems several people are using it and timeouts are a common problem. Kevin > 23, 2023, at 9:11 AM, Cody Cutrer ***@***.***> wrote: > > > aurora_fetch and aurora_mqtt_bridge are using the exact same code to communicate with your heat pump, just providing different interfaces for you to interact with it. If you're having issues running it in systemd, your first step would be to run the bridge directly in your terminal, and not under systemd, to ensure it's not any sort of issue with running as a different user. The next step may be for me to allow the timeout to be configurable, so you can extend it to see if that helps. > > The libffi comment is a red herring. As long as the gem install command works, it doesn't really matter which version you have. > > As far as a specific USB adapter, that's not true. The gem should work with anything that presents itself as a serial port to the operating system, and doesn't have any weird idiosyncrasies (like requiring an additional line being asserted in order to write - any adapter based on the MAX485 chip will have this problem). The issue with the discussion on different serial chipsets ended up being a root cause of the MAX485. All that said, I simply provide a recommendation of the one I own and have tested. > > Keep in mind that this is simply a hobby project to me. I don't get any compensation from it, and developed it for my own personal use. I'm of the opinion that I should share my work freely with others, so provide it here on GitHub. I try to answer questions and help people troubleshoot as I'm able, but have no obligation to do so, and definitely will not be purchasing and spending the time to test myriad RS485 adapters in order to "certify" them. > > The last change to timeouts or actual communication with the unit is 23a4bcc , which was quite some time ago. I don't know what version you were previously using though. It's also possible that your unit isn't responding to a register that the mqtt bridge is assuming exists. aurora_fetch has extra logic to make smaller requests or to simply ignore individual registers that are timing out. If you can email me ***@***.*** ***@***.***>) a YAML file produced with aurora_fetch /dev/ttyHeatPump valid --yaml > myheatpump.yml, I may be able to tell if this is the problem. > > — > Reply to this email directly, view it on GitHub , or unsubscribe . > You are receiving this because you authored the thread. >
jim0020 commented 5 months ago

Similar problems here. Same situation, installed, working fine. Restart due to power flicker, now it will go 20, 40, 90 minutes, even 5 hours before aurora_mqtt_bridge gets another set of data. Restarting the app, or the computer doesn't help.

kskenyon commented 5 months ago

Sometimes restarting the AWL helps but not always. Could be a coincidence. Fatfingered from my iPhoneOn Mar 16, 2024, at 10:43 AM, jim0020 @.***> wrote: Similar problems here. Same situation, installed, working fine. Restart due to power flicker, now it will go 20, 40, 90 minutes, even 5 hours before aurora_mqtt_bridge gets another set of data. Restarting the app, or the computer doesn't help.

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: @.***>

jim0020 commented 5 months ago

No AWL here, just direct connect using the Readme file linked DSD TECH SH-U11 USB to RS485 RS422 Converter with FTDI FT232R Chip Work for Modbus.

0n3man commented 5 months ago

My first thought was you should try using the aurora_fetch tool that comes with this package. Then I looked back through this thread and see the person that wrote this code made this exact suggestion. Stop aurora5_mqtt_bridge and then run his suggestion

aurora_fetch /dev/ttyHeatPump valid --yaml > myheatpump.yml

Where ttyHeatPump has to be changed to match your tty device. I'd run aurora_fetch multiple times to see if it can keep reading the register values.

kskenyon commented 5 months ago

Oh. I go through an AWL but it does act the same. Haven’t tried direct since I use the WF website too. Fatfingered from my iPhoneOn Mar 16, 2024, at 4:27 PM, Brian P @.***> wrote: My first thought was you should try using the aurora_fetch tool that comes with this package. Then I looked back through this thread and see the person that wrote this code made this exact suggestion. Stop aurora5_mqtt_bridge and then run his suggestion aurora_fetch /dev/ttyHeatPump valid --yaml > myheatpump.yml Where ttyHeatPump has to be changed to match your tty device. I'd run aurora_fetch multiple times to see if it can keep reading the register values.

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: @.***>

kskenyon commented 5 months ago

I’ve always assumed it was a quirk with the USB to RS485 adapter I am using. Fatfingered from my iPhoneOn Mar 16, 2024, at 4:30 PM, Kevin Kenyon @.> wrote:Oh. I go through an AWL but it does act the same. Haven’t tried direct since I use the WF website too. Fatfingered from my iPhoneOn Mar 16, 2024, at 4:27 PM, Brian P @.> wrote: My first thought was you should try using the aurora_fetch tool that comes with this package. Then I looked back through this thread and see the person that wrote this code made this exact suggestion. Stop aurora5_mqtt_bridge and then run his suggestion aurora_fetch /dev/ttyHeatPump valid --yaml > myheatpump.yml Where ttyHeatPump has to be changed to match your tty device. I'd run aurora_fetch multiple times to see if it can keep reading the register values.

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: @.***>

jim0020 commented 5 months ago

anybody looked at this from the rmodbus gem: https://github.com/rmodbus/rmodbus/issues/47

jim0020 commented 1 month ago

For me it's now running reliably after modifying the systemd script. Seems the file which sets the ruby environment variables doesn't get run by the systemd /etc/systemd/system/aurora_mqtt_bridge.service script. The ruby envionment variables need to be set for aurora_mqtt_bridge to work. This is done by the file $GEM_HOME/environment, which may not be automatically run by the shell used for systemd service files. Bundler generates a $GEM_HOME/wrappers/aurora_mqtt_bridge file which sets the environment and then runs aurora_mqtt_bridge. One problem is it seems that you can't use environment variables in systemd service files, so the paths have to be hard coded. If I modify the service file's ExecStart to use the wrapper file, it runs fine. Replace the below values enclosed with <> with the appropriate values for your setup:

# File:  /etc/systemd/system/aurora_mqtt_bridge.service
[Unit]
Description=Aurora MQTT Bridge

[Service]
User=<my-user>
ExecStart=<value for $GEM_HOME>/wrappers/aurora_mqtt_bridge /dev/ttyUSB0 mqtt://<mqtt-user>:<mqtt-password>@<mqtt-server>:1883/
Restart=always
RestartSec=3s

[Install]
WantedBy=multi-user.target

This is what worked for me, YMMV.