Hey there, I am having one heck of a time trying to get my application connected to my RaZberry z-wave controller on a RPi3, which communicates over /dev/ttyAMA0.
In order to communicate with the controller, I need the dialout group to have read/write access. Below is the following udev rule I have set to accomplish this:
KERNEL=="ttyAMA0", GROUP="dialout", MODE="0660", SYMLINK+="zwave"
I also make sure that my udev rules are loaded properly by running this script in CMD as described here:
#!/bin/bash
mount -t devtmpfs none /dev
udevd &
udevadm trigger
I also read that serial-getty might also try and access /dev/ttyAMA0, so I run this command to prevent that from happening as well:
systemctl mask serial-getty@ttyAMA0.service
I am accessing it over /dev/ttyAMA0, which has a known overlap with bluetooth. To turn off bluetooth I set dtoverlay=pi3-disable-bluetooth in config.txt. Below is my full full config.txt:
dtparam=audio=on
core_freq=250
enable_uart=1
dtoverlay=pi3-disable-bt
force_turbo=1
Upon boot, it appears that /dev/ttyAMA0 gets the correct permissions set (crw-rw---- root dialout), but upon trying to communicate with my controller, the permissions get reset to (crw--w---- root tty). Any ideas why this change is occurring?
Hey @jkrusinski
That certainly sounds strange, which version of resinOS and what variant (-dev or vanilla) are you using?
Cameron
I am using Resin OS 2.7.8+rev1 (dev)
I happened upon part of the documentation that listed the differences between the development and production versions of ResinOS and noticed it mentioned that one of the features was attaching the getty console to tty1 and serial, which my z-wave controller uses. As a last ditched attempt to finally get this working I decided to use the production version of ResinOS and low and behold it worked perfectly.
Any ideas on what settings on the dev version of ResinOS would have to be reconfigured to keep this overlap from occurring? I am surprised that masking serial-getty didn’t do the trick. I would like to be able to use the development version of ResinOS if possible.
1 Like
@CameronDiver thanks for starting this thread, I’ve been pulling out my hair for days now and was about to give up on the whole containerized approach for Z-Way. I just switched to a production image with the console=tty1, dtoverlay=pi3-disable-bt and enable_uart=1 changes and Z-Way 3.0 works out of the box.
Out of curiosity: did you ever get this to work properly on a development device?
Hey @vicdelfant
We use some serials on the dev image for debugging purpose so you might not be able to use them, you can try to mask serial-getty service to see if it works. Good to know that it works out of the box with production balenaOS image.