ElkM1 at serial:///dev/ttyS0:115200 disconnected

[meierthomas]

The problem

Elk M1 can't connect to the serial port on my HA instance running on VirtualBox (I'm rebuilding Home Assistance - environment see below). Log file attached.

ElkM1 log.txt

I had Elk M1 running on my Home Assistance instance with HA OS 6.2, core-2021.9.5 and supervisor-2022.04.0

What version of Home Assistant Core has the issue?

core-2022.4.4

What was the last working version of Home Assistant Core?

core-2021.9.5

What type of installation are you running?

Home Assistant OS

Integration causing the issue

Elk M1

Link to integration documentation on our website

https://www.home-assistant.io/integrations/elkm1/

Diagnostics information

No response

Example YAML snippet

No response

Anything in the logs that might be useful for us?

No response

Additional information

No response

[probot-home-assistant[bot]]

elkm1 documentation elkm1 source _{^{(message by IssueLinks)}}

[probot-home-assistant[bot]]

Hey there @gwww, @bdraco, mind taking a look at this issue as it has been labeled with an integration (elkm1) you are listed as a code owner for? Thanks! _{^{(message by CodeOwnersMention)}}

[gwww]

@bdraco Timeout waiting for login event is the log message of interest. I don't yet understand why it is happening for here. Is it because of serial port?? Still looking.

FYI... I resurrected the test-serial program in the bin directory. It works pretty well for replaying a session from an Elk by parsing the logs.

Edit 1: The new discovery code changed config_flow such that I can no longer configure a serial ElkM1. When I get to the manual entry screen the URL field is not longer there. So there's the first bug? I will configure with YAML.

Edit 2: perhaps the solution is to backport the login event fix where the lib was bumped to 1.2.2. The lib in use in this bug report should be 1.2.0 if I understand correctly.

[bdraco]

Edit 1: The new discovery code changed config_flow such that I can no longer configure a serial ElkM1. When I get to the manual entry screen the URL field is not longer there. So there's the first bug? I will configure with YAML.

If there isn't a discovery or the discovered device is already setup you will get this screen where you can do serial:

I suppose there is a use case where you have multiple systems and some are connected via IP that user doesn't want to setup in Home Assistant (otherwise they would be ignored and they get the screen above), and some are serial that we need to handle?

[bdraco]

Edit 2: perhaps the solution is to backport the login event fix where the lib was bumped to 1.2.2. The lib in use in this bug report should be 1.2.0 if I understand correctly.

It looks like #69483 still cherry-pick's cleanly to rc so I'll tag it for backport

[meierthomas]

Does the above mean that this was added to core-2022.4.6? If yes, I don't have good news as the serial port still disconnects after the upgrade to 2022.4.6 - see attached log taken after the upgrade of the core

Elk M1 log.txt .

[bdraco]

This looks like a buffering problem

2022-04-21 22:33:22 DEBUG (MainThread) [elkm1_lib.proto] write_data '0Bsd000020065' 2022-04-21 22:33:27 DEBUG (MainThread) [elkm1_lib.proto] write_data '07ps00026' 2022-04-21 22:33:27 DEBUG (MainThread) [elkm1_lib.elk] got_data '1BSD00002Garage 001D PS00000000000000000000000000000000000000000000000000000000000000062' 2022-04-21 22:33:27 ERROR (MainThread) [elkm1_lib.elk] Invalid message '1BSD00002Garage 001D PS00000000000000000000000000000000000000000000000000000000000000062' Traceback (most recent call last): File "/usr/local/lib/python3.9/site-packages/elkm1_lib/elk.py", line 145, in _got_data self._message_decode.decode(data) File "/usr/local/lib/python3.9/site-packages/elkm1_lib/message.py", line 83, in decode raise ValueError(error_msg) ValueError: Incorrect message length

[gwww]

This log is much different than the previous log. The previous log did not have any got_data logs in it. This log is receiving lots of data, with the occasional error (checksum error -- which could be the buffering issue you mention). And the "random" disconnects... I wonder if the way to debug this is custom integration with more debug messages?

[bdraco]

I would have expected 07ps00026 didn't get written right after 0Bsd000020065 since there was no response yet, but the I/O is async so it could simply be that the exception is we will always get a complete response from a read, but it looks like its possible to get multiple.

Seems like a classic suffering from buffering problem: https://perl.plover.com/FAQs/Buffering.html

[bdraco]

It looks like we buffering correctly here https://github.com/gwww/elkm1/blob/main/elkm1_lib/connection.py#L237

[gwww]

Correctly?? Not parsing what you meant.

[bdraco]

My panel always seems to respond with a single message at a time.

This panel seems to sometimes get multiple messages in a single read

It looks like we are breaking up the messages here https://github.com/gwww/elkm1/blob/main/elkm1_lib/connection.py#L237 and keeping the remaining buffer to process later which is the correct behavior.

I'm wondering if this panel is somehow responding with "\n" instead of "\r\n"

Its not really possible to tell from the log since we would need the log the data before its decoded here https://github.com/gwww/elkm1/blob/main/elkm1_lib/connection.py#L234

[bdraco]

I think this line should be decoding as "ascii" instead of "ISO-8859-1" but I don't think thats the issue

https://github.com/gwww/elkm1/blob/main/elkm1_lib/connection.py#L236

[gwww]

In this sequence:

2022-04-21 22:30:31 DEBUG (MainThread) [elkm1_lib.proto] write_data '06ss0054'
2022-04-21 22:30:36 DEBUG (MainThread) [elkm1_lib.proto] write_data '06az005F'
2022-04-21 22:30:41 DEBUG (MainThread) [elkm1_lib.proto] write_data '06zd005C'
2022-04-21 22:30:46 DEBUG (MainThread) [elkm1_lib.proto] write_data '06zp0050'
2022-04-21 22:30:48 DEBUG (MainThread) [elkm1_lib.proto] disconnected callback

The writes are timing out. Note the 5 second difference between each write - which is the waiting for reply timeout. Not sure what is causing the disconnect though. It is coming from the serial library.

On the next connect, it is a bit different:

2022-04-21 22:30:49 DEBUG (MainThread) [elkm1_lib.proto] write_data '0Bsd000050062'
2022-04-21 22:30:49 DEBUG (MainThread) [elkm1_lib.elk] got_data '1BSD00005Entry Hallway 003D'
2022-04-21 22:30:49 DEBUG (MainThread) [elkm1_lib.proto] write_data '0Bsd000060061'
2022-04-21 22:30:49 DEBUG (MainThread) [elkm1_lib.elk] got_data 'llerdoor Reed 00BC'
2022-04-21 22:30:49 ERROR (MainThread) [elkm1_lib.elk] Invalid message 'llerdoor Reed 00BC'
File "/usr/local/lib/python3.9/site-packages/elkm1_lib/elk.py", line 145, in _got_data
File "/usr/local/lib/python3.9/site-packages/elkm1_lib/message.py", line 83, in decode
2022-04-21 22:30:54 DEBUG (MainThread) [elkm1_lib.proto] write_data '07ps00026'
2022-04-21 22:30:54 DEBUG (MainThread) [elkm1_lib.proto] disconnected callback

The first bunch of messages work fine and then it flames out with a bad message, which triggers a disconnect. My theory on the disconnect is that in the pyserial lib it will disconnect if there is a parity error or something like that.

The third disconnect is different still. Everything going along well, very close to being fully synced and this it just flames out. No indication of anything going wrong.

2022-04-21 22:31:18 DEBUG (MainThread) [elkm1_lib.elk] got_data '1BSD02129USER 129 009D'
2022-04-21 22:31:18 DEBUG (MainThread) [elkm1_lib.proto] write_data '0Bsd021300061'
2022-04-21 22:31:18 DEBUG (MainThread) [elkm1_lib.elk] got_data '1BSD02130USER 130 00AD'
2022-04-21 22:31:18 DEBUG (MainThread) [elkm1_lib.proto] write_data '0Bsd021310060'
2022-04-21 22:31:18 DEBUG (MainThread) [elkm1_lib.proto] disconnected callback

What to conclude? I believe the backported fix helped. There was definitely a problem getting stuck waiting for login. There is something else going on which I have not observed before... seems like the serial link is flaky rather than the software. Or maybe a new underlying dependency has changed and catches serial link problem??

pyserial has not changed since Nov 2020 -- I don't think that is the cause. pyserial-asyncio changed in Sept 2021 from 0.5 to 0.6 but the changes appear to be docs only.

Maybe try going back to old HA version and see if that's working still is the first step. And provide logs from that as well. @bdraco what do you think? @meierthomas would that be possible?

In the meantime, I beefed up the disconnect log to include the exception and I can push that. I will look at additional logs in the got_data area but worry about too much logging.

[bdraco]

If we get logging of the raw binary data in data_received before it’s decoded it would probably give another clue as to what’s going on

[meierthomas]

Thanks for this massive amount of troubleshooting @bdraco and @gwww as this is way above my head :)

There's definitely an issue with data as 2022-04-21 22:30:49 DEBUG (MainThread) [elkm1_lib.elk] got_data 'llerdoor Reed 00BC' should read Rollerdoor Reed whereas the 'Ro' is chopped off the message.

@bdraco am I able for me to create the log of the raw binary data in data_received with the current infrastructure?

@gwww I can definitely build an instance of an older HA version but how would I access prior images?

[bdraco]

@bdraco am I able for me to create the log of the raw binary data in data_received with the current infrastructure?

Its not possible without changing the code at the moment

[gwww]

I'm am pondering what is happening right now. I just verified that the serial libs have not changed. Neither has the code around and near where this error is happening. This is pretty low level. Before we go too much further, lets play 20 questions ;)

Before that, here is what I'm thinking. I think something is wrong hardware wise in your setup. The type of error that we are seeing is coming right from the serial library. I do believe that there is a chance that it is software, but that seems unlikely given the information we have so far.

So... (try to answer all the questions, and if you think of anything else put that in too!)

What has changed in your setup recently? Anything at all around how you are connecting whatever you are running HA on? Anything on ports? Any hardware changes, even minor? Did you perhaps more the serial port from one port to another? Any config changes on the ElkM1? Any software updates on the ElkM1? Did you move the HA computer, i.e.: is the serial cable a new one? A longer one?

There are two possible paths to debug that we can think of at the moment. One is back out to the old HA version that was working. Even if it is just enough to get it connected to your Elk and get us a log.

The other path is that we add some more debug logs and then you would have to install a custom component which would download a new lib with more logging. Are you familiar with installing a custom component? I'm working on the logs now.

[gwww]

Alright... Here is a link to a custom component ElkM1. The only difference being the version of the elkm1_lib that is loaded, which is 1.3.dev0. The dev0 lib has printing of exception info on disconnect and prints the raw data that is received from the serial port (that's as low a level as we can go). Unzip the file in your config/custom_components, restart HA, and send the logs.

https://www.dropbox.com/s/8x9c22ddaaewzpw/elkm1.zip?dl=0

[meierthomas]

Ok here's the log of an earlier HA build - core-2021.9.5 using the official integration. The startup time for Elk M1 is about 10 sec as opposed to 2 mins on the other system.

Elk M1 seems connected and I tried a few motion sensors and they change state on the HA entities

Environment as follows

System Health

version: core-2021.9.5
installation_type: Home Assistant OS
dev: false
hassio: true
docker: true
user: root
virtualenv: false
python_version: 3.9.6
os_name: Linux
os_version: 5.10.53
arch: x86_64
timezone: Australia/Melbourne

GitHub API: ok
Github API Calls Remaining: 5000
Installed Version: 1.12.4
Stage: running
Available Repositories: 1037
Installed Repositories: 16

logged_in: false
can_reach_cert_server: ok
can_reach_cloud_auth: ok
can_reach_cloud: ok

host_os: Home Assistant OS 6.2
update_channel: stable
supervisor_version: supervisor-2022.04.0
docker_version: 20.10.6
disk_total: 62.3 GB
disk_used: 14.4 GB
healthy: true
supported: true
board: ova
supervisor_api: ok
version_api: ok
installed_addons: Samba share (9.5.1), Studio Code Server (5.0.0), Portainer (2.0.0), Duck DNS (1.14.0), Node-RED (11.1.1), InfluxDB (4.2.1), Grafana (7.2.0), TasmoAdmin (0.15.0), ESPHome (2021.9.2), Mosquitto broker (6.0.1), MariaDB (2.4.0), Dnsmasq (1.4.4), Glances (0.13.0), Nginx Proxy Manager (0.11.0)

dashboards: 4
resources: 9
views: 30

mode: storage

api_endpoint_reachable: ok

There are still some invalid messages but I'm not sure this has any impact on the operation Elk M1 core-2021.9.5.txt

Here's the log of the new system running core-2022.4.6 via the custom_component provided by @gwww ElkM1 custom_component on core-2022.4.6.txt

From this we should be able to comfortably exclude any hardware issues, right?

Not sure whether related or not is another issue (documented here) I have with this new system and that's the inability to upgrade to HA OS 7.6 (currently running OS 6.1).

[gwww]

Unfortunately, none of the new log messages triggered.

First the 2021.9 log. There are a lot of exceptions, but it does manage to complete syncing the panel. I'm not going to debug the exceptions as enough has changed that since then that it won't be useful (and there are no other reports of it).

The custom_component log is again something new that none of the other logs have shown. This time there are lots of writes to the panel, every single one of them timing out, and then the integration times out as the sync took too long. Because no data was received we don't see the new log message. Also, we're not seeing disconnects either, so not seeing the exception message because of the "spurious" disconnects.

So, we're not any smarter with these logs. The only thing I can suggest is create a new log. To save some turn around time (it appears that you are in Austrailia) maybe you can check the logs before sending them. Look for the disconnects that you were experiencing and look for "got_data" messages. Something like the snippets I put in this reply above: https://github.com/home-assistant/core/issues/70230#issuecomment-1105499662

Edit 1: @bdraco is there a way to get a dump of the installed environment. In particular I'm thinking something like a pip list.

Edit 2: something else that just struck me, while in the shower ;), could this be an OS/driver thing? When you upgrade to 2022.4 are you also upgrading the OS? If so could you try using the 2021.9 OS with the 2022.4 HA. If you could also provide the system health with each environment you run -- we're grasping for clues at this point. Last - to answer your question I think this is a software problem, not hardware.

[meierthomas]

So you're saying that the new log messages would bet contained in the got_data messages and I'm interested in a few got_data messages before the disconnects? Do we know how these "new log messages" look like?

[gwww]

You don’t need to look for the new messages. As long as the ones I mentioned are in the log were good.

But, the one new message starts with ser_rx. The disconnect is not new but prints the exception with it.

It would also be good to try the old OS with the new 2022.4. That will isolate if an OS change caused this.

[meierthomas]

Is there an archive of old OS versions? Did a search and nothing useful came up.

Also it appears we're looking for a fully synced status. How can I identify that in the log?

Lastly what does 'syncing panel's actually do? Is this a communication from the Elk controller with the wall panel?

[gwww]

Can you find it here https://github.com/home-assistant/operating-system/releases

[meierthomas]

Can you find it here https://github.com/home-assistant/operating-system/releases

Perfect. With this I can go back in time and build VMs using earlier versions. I added a few more queries about the syncing which would be useful to understand

[meierthomas]

So just thought of something else. The official HA doc states to be running firmware 5.2.0 or higher. I'm running 5.2.8 or higher. Could there be an issue with this version? What are you guys successfully running?

[gwww]

I’m running HA OS 7.5.

What’s important for your setup at the moment is that you run the OS version you were running when you had 2021.9 so that we can determine if there’s an OS regression. It’s looking more likely to be the cause. You can run it with the custom Elk I gave you yesterday.

[meierthomas]

Ok so I create a new VM based on the OS version used with 2021.9, install the official Elk M1 integration and the custom_component you provided, turn on debug logging for ELk M1 and then check the logs. Did I get that right?

Also is there a similar repository with previous core versions to test or should I simply stay on the latest 2022.4.6 and check the various OS versions?

[meierthomas]

So I created a VM on HA OS 6.2 (which was used when running 2021.0) and core-2022.4.6. There are now some ser_rx records. There still are some serial disconnect messages but data seems to get received get_data. The Elk M1 startup takes 20 secs as opposed to 120.

Do we get any smarter from these logs? OS6.2_core-2022.4.6.txt

[gwww]

In the logs there is this:

2022-04-23 19:09:00 ERROR (MainThread) [elkm1_lib.connection] device reports readiness to read but returned no data (device disconnected or multiple access on port?)
2022-04-23 19:09:00 DEBUG (MainThread) [elkm1_lib.connection] disconnected callback (exception: SerialException)

No conclusion what to do with it yet. But did find this: https://forums.raspberrypi.com/viewtopic.php?t=228315.

Here is the search I used... there is lots more. https://www.google.com/search?&q=device+reports+readiness+to+read+but+returned+no+data+(device+disconnected+or+multiple+access+on+port%3F) -- if you want to browse through some of these results, see if that triggers any thoughts for you.

What hardware are you running on?

How is the the Elk connected to the the hardware? Using a serial to USB converter, if so which one?

[mstarks01]

I'm having a similar issue but not with serial.

Logger: elkm1_lib.elk
Source: /usr/local/lib/python3.9/site-packages/elkm1_lib/elk.py:129
First occurred: 11:26:13 AM (5 occurrences)
Last logged: 11:30:14 AM

ElkM1 at elks://elk.federation disconnected

Btw, the address elk.federation is valid and can be resolved from Home Assistant.

This worked before the Elk configuration moved outside of the yaml. Perhaps it is related to me deleting the other instance that was being discovered.

[gwww]

@mstarks01 try IP address. I’ll let @bdraco aay for sure but don’t believe domain works any longer. I’m not sure if it’s more nuanced than that.

[bdraco]

Domain should still work. It just won’t work with discovery and the unique id/mac will never be found since it needs to link it to the ip

@mstarks01 Would you please open a new issue so we don’t get this confused with the serial investigation in this issue.

[gwww]

Looking at the log further (and after coffee) I see this:

2022-04-23 19:08:47 DEBUG (MainThread) [elkm1_lib.connection] write_data '07ps10025'
2022-04-23 19:08:47 DEBUG (MainThread) [elkm1_lib.connection] ser_rx: b'47PS1000'
2022-04-23 19:08:47 DEBUG (MainThread) [elkm1_lib.connection] ser_rx: b'00000000'
2022-04-23 19:08:47 DEBUG (MainThread) [elkm1_lib.connection] ser_rx: b'00000000'
2022-04-23 19:08:47 DEBUG (MainThread) [elkm1_lib.connection] ser_rx: b'00000000'
2022-04-23 19:08:47 DEBUG (MainThread) [elkm1_lib.connection] ser_rx: b'00000000'
2022-04-23 19:08:47 DEBUG (MainThread) [elkm1_lib.connection] ser_rx: b'00000000'
2022-04-23 19:08:47 DEBUG (MainThread) [elkm1_lib.connection] ser_rx: b'00000000'
2022-04-23 19:08:47 DEBUG (MainThread) [elkm1_lib.connection] ser_rx: b'00000000'
2022-04-23 19:08:47 DEBUG (MainThread) [elkm1_lib.connection] ser_rx: b'000000061\r'
2022-04-23 19:08:47 DEBUG (MainThread) [elkm1_lib.connection] ser_rx: b'\n'
2022-04-23 19:08:47 DEBUG (MainThread) [elkm1_lib.connection] got_data '47PS100000000000000000000000000000000000000000000000000000000000000000061'
2022-04-23 19:08:47 DEBUG (MainThread) [elkm1_lib.connection] write_data '07ps20024'
2022-04-23 19:08:47 DEBUG (MainThread) [elkm1_lib.connection] ser_rx: b'000000000000000000000060\r\n' ***1
2022-04-23 19:08:47 DEBUG (MainThread) [elkm1_lib.connection] got_data '000000000000000000000060'
2022-04-23 19:08:47 ERROR (MainThread) [elkm1_lib.connection] Invalid message '000000000000000000000060'

See the got_data that begins with 47PS1. That's a good packet and was pieced together through 10 ser_rxs.

The Elk does the right thing then asks for the next bank of lighting data, the write_data 07ps20024. Notice what comes back does not look like the previous request. The line annotated with ***1 is missing the beginning of the packet. There are many possible causes. Buffer overrun, bad drivers, flaky hardware, flaky connect.

I'm kind of at the point where I really don't know what else to say. Can you swap some hardware in to try out if that makes a difference. Also read the link(s) in my previous comment and see if that triggers any thoughts for you. And let me know what your hardware setup is. What HA is running on, and all the bits that connect it to the Elk panel. I'm guessing some sort of USB to serial dongle is involved.

@bdraco any other thoughts?

[bdraco]

That looks like a hardware problem to me as well. Its clearly getting back bad data from the port

[mstarks01]

@bdraco Sure, here ya go.

[meierthomas]

Looking at the log further (and after coffee) I see this:

2022-04-23 19:08:47 DEBUG (MainThread) [elkm1_lib.connection] write_data '07ps10025'
2022-04-23 19:08:47 DEBUG (MainThread) [elkm1_lib.connection] ser_rx: b'47PS1000'
2022-04-23 19:08:47 DEBUG (MainThread) [elkm1_lib.connection] ser_rx: b'00000000'
2022-04-23 19:08:47 DEBUG (MainThread) [elkm1_lib.connection] ser_rx: b'00000000'
2022-04-23 19:08:47 DEBUG (MainThread) [elkm1_lib.connection] ser_rx: b'00000000'
2022-04-23 19:08:47 DEBUG (MainThread) [elkm1_lib.connection] ser_rx: b'00000000'
2022-04-23 19:08:47 DEBUG (MainThread) [elkm1_lib.connection] ser_rx: b'00000000'
2022-04-23 19:08:47 DEBUG (MainThread) [elkm1_lib.connection] ser_rx: b'00000000'
2022-04-23 19:08:47 DEBUG (MainThread) [elkm1_lib.connection] ser_rx: b'00000000'
2022-04-23 19:08:47 DEBUG (MainThread) [elkm1_lib.connection] ser_rx: b'000000061\r'
2022-04-23 19:08:47 DEBUG (MainThread) [elkm1_lib.connection] ser_rx: b'\n'
2022-04-23 19:08:47 DEBUG (MainThread) [elkm1_lib.connection] got_data '47PS100000000000000000000000000000000000000000000000000000000000000000061'
2022-04-23 19:08:47 DEBUG (MainThread) [elkm1_lib.connection] write_data '07ps20024'
2022-04-23 19:08:47 DEBUG (MainThread) [elkm1_lib.connection] ser_rx: b'000000000000000000000060\r\n' ***1
2022-04-23 19:08:47 DEBUG (MainThread) [elkm1_lib.connection] got_data '000000000000000000000060'
2022-04-23 19:08:47 ERROR (MainThread) [elkm1_lib.connection] Invalid message '000000000000000000000060'

See the got_data that begins with 47PS1. That's a good packet and was pieced together through 10 ser_rxs.

The Elk does the right thing then asks for the next bank of lighting data, the write_data 07ps20024. Notice what comes back does not look like the previous request. The line annotated with ***1 is missing the beginning of the packet. There are many possible causes. Buffer overrun, bad drivers, flaky hardware, flaky connect.

I'm kind of at the point where I really don't know what else to say. Can you swap some hardware in to try out if that makes a difference. Also read the link(s) in my previous comment and see if that triggers any thoughts for you. And let me know what your hardware setup is. What HA is running on, and all the bits that connect it to the Elk panel. I'm guessing some sort of USB to serial dongle is involved.

@bdraco any other thoughts?

I'm running HA on a dedicated Dell OptiPlex 790 - first released in 2011 :) with 20GB of RAM. It runs Fedora 35 and VirtualBox 6.1. It has a built in serial port and connects to the M1 Gold via a 2m serial cable. I have a few test versions of HA based on the troubleshooting we started here but at any point when logs were provided I made sure only the one HA instance is running so attempting to access the serial port while another is running is not the case.

The serial port is setup as a host device in VirtualBox

I don't have any other computers with dedicated serial ports or a USB to serial adapter so will need to get one to try this. I'll stay with the same setup (i.e. OS 6.2 and core-2022.4.6) in the first instance and report back. Given the serial port device will change with a USB dongle how would I find out in Fedora what the name of the new device is?

[gwww]

So we’re pretty sure that this is either a hardware issue or software issue way bellow in the software stack than we can handle. It could be the new hassos doesn’t deal well with VirtualBox.

But here’s a workaround. Install ser2net on your host OS. On your guest OS connect to the Elk by connecting non secure to the ser2net.

Here’s a post that might help. https://forums.virtualbox.org/viewtopic.php?t=74265

[meierthomas]

Ok.

To take out the VirtualBox from the equation I have gone back to Fedora 30/VirtualBox 5.2.44 system. This setup was running fine for a long time. I still can't connect. So I have contacted the Elk M1 Installer as it increasingly.looks like a hardware issue as you suspected one possible scenario to be.

Will report back once we have an answer on that

[meierthomas]

The attached log is from the Raspberry Pi with the latest HA instance and the custom_components/elkm1 from @gwww and the Elk M1 control connected via a USB to Serial adapter.

It doesn't show any errors. From what you can see does this look alright? The sensors seem to resond ok...

home-assistant.log

[gwww]

Looks good to me! I see you are running the Elk custom component. No need to do that any longer. Congrats!

[meierthomas]

Looks good to me! I see you are running the Elk custom component. No need to do that any longer. Congrats!

Thanks. Been a journey but I would also like to thank you and @bdraco. Wouldn't be here without your kind help.

Having said this the above result essentially seems to confirm an issue with VirtualBox, right? I remember having seen /dev/ttyUSB0 pointing to the USB - Serial adapter when I did dmesg | grep tty on the Dell box. And using /dev/ttyUSB0 in the Elk M1 integration on Home Assistant threw all those disconnects we saw in the logs. Hence my conclusion.

What I'm still trying to do is to get ser2net to work on the Pi as I still need to get the Elk M1 control data onto Home Assistant running on the Dell VM but hopefully that shouldn't be too difficult. If you're ok I leave the issue open until we have that confirmation in case someone else faces this issue so that they also have a (not so elegant) resolution path.

[github-actions[bot]]

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates. Please make sure to update to the latest Home Assistant version and check if that solves the issue. Let us know if that works for you by adding a comment 👍 This issue has now been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.