Failing to start Z-Way and RaZberry via ttyAMA0 on Raspberry Pi

Hey all. I am trying to get z-wave communication working via a RaZberry board. When I create a stand alone instance with JESSIE and then install z-way everything works. When I deploy JESSIE with z-way via there is a problem in communication with the RaZberry board.

The Pi communicates with RaZberry board via /dev/ttyAMA0. Does resin do something with ttyAMA0 that blocks communication, or do I need to enable is separately?

Has anybody had any success with this?

Hey @m-lablablab what version of resinOS are you trying this on and can you tell me what raspberry pi version you are using?

Hey @shaunmulligan thanks for looking into it

I am using.
Resin OS 1.19.0
Raspberry Pi 3 Model B V1.2

Hey @shaunmulligan, any update or any ideas on how I can get ttyAMA0 to work?

Hey, Raspberry Pi 3 has a known overlap of the hardware between the Bluetooth and the serial connection that I believe is ttyAMA0 (you can search the forums for a lot of discussion on that). If I recall correctly, need to disable the onboard Bluetooth by applying the pi3-miniuart-bt overlay. That can be done either in the config.txt on the SD card dtoverlay=pi3-miniuart-bt, or more practically by setting a Fleet Configuration, or Device Configuration of RESIN_HOST_CONFIG_dtoverlay equal to pi3-miniuart-bt. That should reconfigure the Pi to do Bluetooth differently, and free up AMA0. Might also need to set force_turbo=1 (or rather in the dashboard RESIN_HOST_CONFIG_force_turbo equal to 1).

This might or might not be all that you need, but definitely part of the process… Will be checking some more later, just don’t have the hardware at the moment.

That solved it. THANK YOU.

how would “force_turbo=1” affect the serial port?

As much as I can recall, force_turbo might affects the serial port because it seems like the UART frequency/bitrate on the Raspberry Pi is somehow tied to the CPU frequency, which is normally dynamic (creating a lot of transient UART issues possibly), while force_turbo will pin the CPU frequency => stabilize the UART clock. You can try running it without it, I’ve based it on some forum posts, including

As a sidenote, Raspberry Pi hardware control can be quite a bit of black magic, quite a few the config.txt settings have side effects that can be only understood historically (the start_x=1 needed for the PiCamera to be enabled is another example:) It takes some Googling usually. :slight_smile: Glad it worked for you after all!

There’s more info about pi3-miniuart-bt (and pi3-disable-bt) at

IIRC the force_turbo option was an ‘early fix’ for the default mini-uart being unstable on the GPIO pins - it’s no longer needed and if you’re not using pi3-miniuart-bt you should instead use enable_uart=1, and then modify your software to use the mini-uart (ttyS0 instead of ttyAMA0).

There’s also but unfortunately that’s not kept up to date very well.