I’m trying to send commands to my Vista 20p panel, and I believe that I have everything setup properly, but the setup isn’t working. I’ve enabled sending commands in my openhab.cfg:
alarmdecoder:send_commands_and_compromise_security=true
And I’ve also setup the keypad in my sitemap using the example in the Wiki entry for the alarmdecoder binding. Has anyone gotten this to work? Can someone tell me what the next step is for debugging my setup?
I’m coming back to this and still can’t see anything in the logs even though I have them set to TRACE level. Can anyone comment? Alternatively, can anyone that has this alarm panel suggest an alternative that will allow me to remotely arm/disarm?
I’m just now setting this up myself and running into an issue with the codes not working. I can receive all the info from the panel perfectly fine - status, zone status, etc. The problem is when I try to send a code or anything to the panel, I’m not getting anything.
I know it’s working on the AD2USB side as I can input content via the serial interface manually and it works. But it seems something in OH is not working properly. The downside, I don’t know a damn about coding to dig in and identify what could be wrong here. I’m hoping someone else is able to brighten up or illuminate what we may be missing.
I know @Bernd_Pfrommer was the original creator of the binding. I had chatted with him almost 2yrs ago when he first created it. I planned to do a run through on helping update the documentation and the details needed to setup the relays. Some updates have also relegated some of the item definitions as unnecessary, so I figured I’d could clean up and make a pull request on that to help out. I hope Bernd is still around and can help us identify this though.
At some point this was working for me, definitely. Not sure what has changed. Can somebody post the debug level logs, their items files etc?
Well … I’ve got a hunch, but I will need to continue monitoring and further test some things out with my setup. I turned on TRACE level logging for the alarm decoder binding, and didn’t see much extra info. It looked as though everything was operating as expected. Can see all the zone info properly, can see the details display messages, everything looked good. But key presses just were not fully translating.
I went to bed last night, this afternoon ran some more tests. Was still not getting anything. So I decided to fire up minicom and watch the output to see if I could do at the same time as OH so I could see if data was going across at all. Two terminal windows, one inside Karaf console, other in minicom. Used the test keypad, and suddenly the keypresses were making it across. System started arming, and disarming, but some messages got wonky - probably because the binding and minicom were trying to read the output and I was inundating the system with presses. Now I exited minicom with no reset, continued testing, working. Entered minicom again and exited with a reset. Keypress still working.
My hunch, is that somehow the AD2USB device was not getting started? Somehow in the process of OH startup perhaps, the serial port wasn’t being first initialized to allow the transfer of data across? I’m going to try restarting the system at some point that is hooked up to see what happens.
The only downside I have at this point, is I’m relegated to multiple updates to the item with each number press required, vs being able to parse a whole string across to the keypad. Any way this could be achieved differently @Bernd_Pfrommer? And I will leave my logs on trace for now so I can see what I may get if it faults up again on me and post it here.
And in a followup to answer my own question, it appears I can create ANY map I’d like in the item, allowing me to setup my own translations. So I can create a SWITCH instead, and map ON=xxx, OFF=xxx or similar.
Is there a way to simply set a string to be passed without mapping to another string first? For ex:
Switch alarm_enable "Enable Alarm" (g_alarm){ alarmdecoder="SEND#12345", autoupdate=false }
When trying this I get an error that it’s not formatted properly in the Karaf console.
Are you seeing anything in your logs regarding the flag to allow you to send commands to the AD2USB? In my previous attempts with this (on OH 1.8), I would enable sending commands, but not see anything in the logs, even on TRACE level. I am still transitioning to OH2, so I can’t test tonight, but I will try to get it up and running tomorrow to give another datapoint.
On a related note, is there a way to exempt the button presses from logs so that my alarm codes do not find their way into events.log?
That’s correct, I’ve set the appropriate setting in the config file and I do see that message at the start of the system startup that entries are enabled.
That’s an interesting thing I didn’t necessarily think of to turn off the logs. Thought honestly, I’d imagine passing this data through the system in the first place leaves it just as susceptible as being logged. One thing I can suggest is if you have quick-arm functions turned on, you don’t need to enter alarm codes to enable the alarm - just put in ON=POUND2 for Away, or ON=POUND3 for Stay, etc.
Now the only thing needed to be entered is to disable the alarm, further reducing the amount of codes going along the wire at least.
Some further color - it seems that whatever is happening is actually affecting OH on the whole. Or at least affecting ZWave devices as well, but I believe more the whole as suddenly the log:tail I’m viewing of Karaf console freezes and no updates happen - not even for the alarm decoder binding either. If I then open up minicom, it suddenly kicks in again and logs continue to flow and the commands that were entered get pushed through to the Alarm panel.
I don’t know, I’m at a bit of a loss here for solid consistent results. Restarts of openhab have yielded different results too but often do result in the freeze issue followed by a continued processing when I open minicom. It seems to happen essentially right after I’ve input the full alarm code, aka the first 3 digits show as passing along, then when pressing in the 4th, it causes the lockup. Open minicom. Close minicom. Then continue as normal.
Can you try something like this:
Number mySpecialTrigger "" {alarmdecoder="SEND#15=WHATEVA,16=SOMETHINELSE", autoupdate="false"}
If you now send the number 15 to the mySpecialTrigger item, it should send the string “WHATEVA” to the panel, if you send 16 to the mySpecialTrigger item, it should send SOMETHINELSE.
And of course, tie a button in the GUI to send the number 15 to the item when you press the button.
I agree, I was more concerned with how to remotely disarm my system without having the alarm code show up in my item definitions or the logs.
So I’m pulling this out the back end here, but if I’m correct you should be able to modify an item or binding to log at a certain level (TRACE/DEBUG/INFO/WARN/ERR/etc). I would say if you’re ok with the logs missing detail about that binding (aka need to set the log level for debugging ANY time something goes wrong) - you should be able to potentially modify the log level/output of that specific binding. This should suppress those messages showing in the logs. For example, an easy option is to just open Karaf console, set log:set ERROR org.openhab.binding.alarmdecoder - I believe this should set logs to ERROR only so regular keypress events won’t transmit in the logs.
@Bernd_Pfrommer - thanks for that pointer, that’s what I figured out. I was looking if this could be simplified one more level with a autoupdate=false button that when pressed would send a specific command, instead of having to specify an ON=xxx string. No big deal. Maybe a minor alteration if you dive into code again to simplify further. For now, I love the binding and it’s capability.
Now the bigger issue, is the problem with communication with the AD device is creeping back again. I let the system go and used it for about a day with no issue. Yesterday I had to restart the docker container (aka the OH server) - when I went to try and use the AD integration last night, no communication to the AD. So it would appear something is creeping up here with regard to initiating the initial communication with the device. Almost like an initialization string or call that needs to be made before OH will communicate properly. And now I actually can’t get it to re-initialize it seems.
Ok I finally have an error message, and I think it relates to my suspicion of something not initializing properly.
14:41:16.837 [WARN ] [org.apache.karaf.services.eventadmin] - EventAdmin: Blacklisting ServiceReference [{org.osgi.service.cm.ManagedService, org.osgi.service.event.EventHandler}={event.topics=openhab/*, service.pid=org.openhab.alarmdecoder, component.name=org.openhab.binding.alarmdecoder.refreshservice, component.id=180, service.id=315, service.bundleid=194, service.scope=bundle} | Bundle(org.openhab.binding.alarmdecoder_1.9.0 [194])] due to timeout!
It seems if I don’t get the alarm decoder working again within a specified time, it get’s some sort of Blacklisting marking form Karaf.
I confirm that it is now working for me. Were there any changes between the 1.8 binding and 1.9? With 1.8 I did not receive any notification in openhab.log that I could send commands, nor was I able to send any.
You’d have to look at the source code to see what if any differences there are between 1.8 and 1.9, but frankly I don’t think those differences are the root cause of your issues, nor am I convinced that the problem has gone away for good.
I’m not sure this is a binding problem, almost more like a OH framework/system issue. Is the binding starting at all? Does it produce any log messages?
A diagnostic hack would be to use ser2net to expose your serial port on a tcp port, then connect the alarmdecoder binding to that tcp port. Ser2Net has a monitoring feature, so you can see what the binding is writing to the port.
So I’m finally get back to testing this out and trying to resolve the issue, but I’m hitting a wall here. I’m continuing to hit this message:
11:01:02.415 [WARN ] [org.apache.karaf.services.eventadmin] - EventAdmin: Blacklisting ServiceReference [{org.osgi.service.cm.ManagedService, org.osgi.service.event.EventHandler}={event.topics=openhab/*, service.pid=org.openhab.alarmdecoder, component.name=org.openhab.binding.alarmdecoder.refreshservice, component.id=203, service.id=349, service.bundleid=223, service.scope=bundle} | Bundle(org.openhab.binding.alarmdecoder_1.9.0 [223])] due to timeout!
In this case, I decided to stand this up fresh, brand new hardware and OH install, and even attempted switching over to the TCP method using Ser2Net. At first late last night it worked, but again today it’s failing to function. Something seems to be causing an issue, but I can’t successfully see anything in any logging anywhere. It seems the binding is causing some sort of an issue inside of OH, but no logs are indicating what is happening inside the binding to do this.