RPi 3 pre-built issues

[mflembeck]

To get the pre-built 2016-04-29 image up and running on my RPi 3 using wifi to connect to my network required a couple of mods. First, updated wifi network and password in /etc/wpa_supplicant/wpa_supplicant.conf adding the lines:

network={
ssid="network name"
psk="network password"
}

Then I disabled ipv6, so that I could get an IP on my network by creating a file /etc/sysctl.d/local.conf with the line:

net.ipv6.conf.all.disable_ipv6 = 1

The RPi 3 rebooted, got an IP, and was made available at https://alarmdecoder.local. The webapp starts as advertised and I went through the setup for notifications and set the panel address to the enabled available 18. All of that works, but the keypad does not seem to be commanding (i.e., gets status messages, but cannot send arm/disarm commands) and only the "opening device" diagnostic test is successful, all others time out. Log file shows alarmdecoder device opening and closing and also shows manual arms/disarms made from the hardwired panel. I also enabled addresses 19 and 20, tried again on the webapp, but no joy.

Any suggestions? Thanks for any help.

[kevin]

We do not recommend a wireless configuration for this application so we leave that up to the user to configure manually

Now with regard to your other issue - please detail what settings you chose during setup. Also please determine if you can telnet to port 10000 of the pi and command the alarm from there.

It sounds as if maybe there is a multiple things trying to open the com port use.

[mflembeck]

i can connect to the Pi using telnet 192.XXX.XXX.XXX 10000, but no commands (C, =, !, V) are responded to. telnet localhost 10000 results in "connection refused." Same for telnet 127.0.0.1 10000. however, i can reach the webapp at https://alarmdecoder.localhost. Settings: Device Type: AD2PI, location: local device, path: /dev/serial0, baud: 115200, share on network checked, ser2sock config path: /etc/ser2sock, address: localhost, port:10000, panel type: ademco, address: 18, address mask: ffffffff, webapp address mask: ffffffff,

[kevin]

Well that all sounds good - are you sure you've got the ad2pi on the gpio header correctly?

[mflembeck]

yes. the board lights up as expected. and there is one-way communication of status messages from the panel to the ad2pi. the log file shows arms/disarms as well. i guess i will have to put a logic analyzer on the output and see if anything is coming out of the ad2pi to the panel.

[kevin]

So you see messages from the panel but can't send to the panel? Or vice versa? I just want to make sure I'm understanding the problem correctly.

Just a thought - you are providing ground and power to the ad2pi from the panel as well as DI and DO?

You also did enable the address you are using on the ad2pi on the panel side through programming mode?

[mflembeck]

Correct. Can see the messages from the panel. Can not send any commands through the keypad on the web app.

Ground, power, DI, DO, all coming from the ademco board to ad2pi. I'm guessing either DO is not active, disabled, or ad2pi board problem at this point.

Address #18 is enabled on the panel side through programming mode.

Appreciate the help.

[kevin]

Correct. Can see the messages from the panel. Can not send any commands through the keypad on the web app.

Ground, power, DI, DO, all coming from the ademco board to ad2pi. I'm guessing either DO is not active, disabled, or ad2pi board problem at this point.

Address #18 is enabled on the panel side through programming mode.

Appreciate the help.

All I can think of at this point is a bad wire or the address you are using either isn't enabled correctly or there is something else already at that address. If it's none of those, it is possible it is a bad ad2pi, but to be frank we have had a 0% failure rate on them (never had a returned ad2pi unit for failure RMA) - so while it is possible, it is not the first thing on my list.

[mflembeck]

Thanks for your continued help. Based on your hint, i went back and checked the addresses of the existing keypads and found that they were at 17 and 18 (not 16 and 17 as i had assumed). So i enabled 19, went through webapp setup and changed the address to 19 and now get this message in the log (but the webapp still does not appear to be able to command the panel):

2016-05-14 11:23:06,465 WARNING: Discovery: Error 400 - Bad request version ('OK') [in /opt/alarmdecoder-webapp/ad2web/discovery.py:98]

[kevin]

Now that you've figured out the address issue, please try and control the alarm from the ser2sock interface (telnet the alarmdecoder on port 10000) and try and arm and disarm by entering your code as you would to arm and disarm and hit enter (ex: 41122enter, 41121enter)

If you can at least control your alarm from here, we can eliminate the hardware being an issue.

As far as the discovery thread erroring out, I will have to defer to Scott as he has the most intimate knowledge of that portion of the project. But if we could verify the hardware works, that would be great.