DSC Binding - how to send a command string similar to keypad

rsstephens · September 9, 2016, 10:24am

I did do a PR for the 040 and the 070 command changes. However I didn’t include the code for the 901 message. I was thinking it was a little too specific a case to be apart of the binding itself. After I did the PR I thought of another way that might work, and that would be to create another item type for the 901 message. That way the parsing of the incoming message could be done through a rule or script. I will look at doing that in another PR.

I really appreciate your contribution to this. I don’t use the IT100, rather the Envisalink, so I am limited on how the IT100 fully functions. Input like yours really helps to refine the binding for the IT100. Thank you.

rsstephens · November 24, 2016, 4:12pm

Hello @goodfore,

A PR has been submitted with added item types for the 901 and 902 messages called keypad_lcd_update and keypad_lcd_cursor respectively. I was wondering if you would be willing to test the binding: here is a new .JAR file. The items are of type String. I know you did some special coding for the 901 message so this would replace that coding and may require a different approach to get the same results, such as using a rule. Therefore, I would understand if you don’t want to make those changes and test this new version. Thank you.

goodfore · November 24, 2016, 5:52pm

Hi Russell,

I am currently out of the country travelling. When I get home I will make
time to test it.

Thanks,
Joe

rsstephens · November 25, 2016, 10:49am

Thank you, Joe!

goodfore · December 12, 2016, 5:55am

HI @rsstephens,

I am back. For your updated binding, what specific things should I test/look for? 901 is text displaying on the screen, I don’t really know what 902 suppose to do.

Thanks,
Joe

rsstephens · December 12, 2016, 1:27pm

Hello @goodfore,

Are you getting any text feed back for 901? It should change whenever the LCD menu changes. Theoretically you should be able to parse that text in a rule or script to extract information; similar to what you did in the binding. As for 902, it is similar to 901 except it changes whenever the LCD cursor position changes. It is also a string item. Not sure there would be a be a big use for 902. I just need to know if they are working correctly. If you want to test any further that is up to you. I sure do appreciate it. Thank you Joe.

goodfore · January 9, 2017, 9:25am

Hi @rsstephens,

My apologies this took sooooo long. Been busy with kid + holiday. Finally got some time to catch up on things. When I deploy your JAR, I am getting an error in the DSC log.

2017-01-09 01:18:16.450 [ERROR] [o.b.d.i.connector.TCPConnector] - handleIncomingMessage(): Event listener invoking error
java.lang.NumberFormatException: For input string: “0032 Date Time JAN 09/17 2:19a”
at java.lang.NumberFormatException.forInputString(NumberFormatException.java:65) ~[na:1.8.0_111]
at java.lang.Integer.parseInt(Integer.java:580) ~[na:1.8.0_111]
at java.lang.Integer.parseInt(Integer.java:615) ~[na:1.8.0_111]
at org.openhab.binding.dscalarm.internal.model.Keypad.handleEvent(Keypad.java:148) ~[bundlefile:na]
at org.openhab.binding.dscalarm.internal.DSCAlarmItemUpdate.updateDeviceItem(DSCAlarmItemUpdate.java:158) ~[bundlefile:na]
at org.openhab.binding.dscalarm.internal.DSCAlarmActiveBinding.handleDSCAlarmEvent(DSCAlarmActiveBinding.java:1212) ~[bundlefile:na]
at org.openhab.binding.dscalarm.internal.DSCAlarmActiveBinding.dscAlarmEventRecieved(DSCAlarmActiveBinding.java:1114) ~[bundlefile:na]
at org.openhab.binding.dscalarm.internal.connector.TCPConnector.handleIncomingMessage(TCPConnector.java:151) ~[bundlefile:na]
at org.openhab.binding.dscalarm.internal.connector.TCPConnector$TCPListener.run(TCPConnector.java:225) [bundlefile:na]
2017-01-09 01:19:16.324 [ERROR] [o.b.d.i.connector.TCPConnector] - handleIncomingMessage(): Event listener invoking error
java.lang.NumberFormatException: For input string: “0032 Date Time JAN 09/17 2:21a”
at java.lang.NumberFormatException.forInputString(NumberFormatException.java:65) ~[na:1.8.0_111]
at java.lang.Integer.parseInt(Integer.java:580) ~[na:1.8.0_111]
at java.lang.Integer.parseInt(Integer.java:615) ~[na:1.8.0_111]
at org.openhab.binding.dscalarm.internal.model.Keypad.handleEvent(Keypad.java:148) ~[bundlefile:na]
at org.openhab.binding.dscalarm.internal.DSCAlarmItemUpdate.updateDeviceItem(DSCAlarmItemUpdate.java:158) ~[bundlefile:na]
at org.openhab.binding.dscalarm.internal.DSCAlarmActiveBinding.handleDSCAlarmEvent(DSCAlarmActiveBinding.java:1212) ~[bundlefile:na]
at org.openhab.binding.dscalarm.internal.DSCAlarmActiveBinding.dscAlarmEventRecieved(DSCAlarmActiveBinding.java:1114) ~[bundlefile:na]
at org.openhab.binding.dscalarm.internal.connector.TCPConnector.handleIncomingMessage(TCPConnector.java:151) ~[bundlefile:na]
at org.openhab.binding.dscalarm.internal.connector.TCPConnector$TCPListener.run(TCPConnector.java:225) [bundlefile:na]
2017-01-09 01:20:16.359 [ERROR] [o.b.d.i.connector.TCPConnector] - handleIncomingMessage(): Event listener invoking error
java.lang.NumberFormatException: For input string: “0032 Date Time JAN 09/17 2:22a”
at java.lang.NumberFormatException.forInputString(NumberFormatException.java:65) ~[na:1.8.0_111]
at java.lang.Integer.parseInt(Integer.java:580) ~[na:1.8.0_111]
at java.lang.Integer.parseInt(Integer.java:615) ~[na:1.8.0_111]
at org.openhab.binding.dscalarm.internal.model.Keypad.handleEvent(Keypad.java:148) ~[bundlefile:na]
at org.openhab.binding.dscalarm.internal.DSCAlarmItemUpdate.updateDeviceItem(DSCAlarmItemUpdate.java:158) ~[bundlefile:na]
at org.openhab.binding.dscalarm.internal.DSCAlarmActiveBinding.handleDSCAlarmEvent(DSCAlarmActiveBinding.java:1212) ~[bundlefile:na]
at org.openhab.binding.dscalarm.internal.DSCAlarmActiveBinding.dscAlarmEventRecieved(DSCAlarmActiveBinding.java:1114) ~[bundlefile:na]
at org.openhab.binding.dscalarm.internal.connector.TCPConnector.handleIncomingMessage(TCPConnector.java:151) ~[bundlefile:na]
at org.openhab.binding.dscalarm.internal.connector.TCPConnector$TCPListener.run(TCPConnector.java:225) [bundlefile:na]

Please note that IT100 sends a time stamp every minute, in a format like this.

For input string: “0032 Date Time JAN 09/17 2:21a”

I am not sure what is causing the error.

Thanks,
Joe

goodfore · January 9, 2017, 9:47am

Hi @rsstephens,

I have checked my code, I think my approach can still perform the rule method you mentioned.

What I did was in internal/protocol/APIMessage.java, I changed

case LCDUpdate: /* 901 */
                        apiName = "LCD Update";
                        apiDescription = apiCodeReceived + ": Text of the IT-100 menu has changed.";
                        break;

to

  case LCDUpdate: /* 901 */
                        apiName = "LCD Update";
                        apiDescription = apiCodeReceived + ": " + data.substring(5);
                        break;

That way, the text would go to the panel:panel_message item.

Thanks,
Joe

rsstephens · January 10, 2017, 11:33am

Hmm, according to the documentation the IT100 doesn’t send time stamps or time broadcasts formatted like that. I wonder if that is the keypad display information being sent when the time changes. The binding may not be handling the information correctly. I will look into it closer. Thanks Joe.

rsstephens · January 12, 2017, 11:35am

Hello Joe,

I think I have fixed the bug. If you are willing, would you be able to test the new JAR? It is located here. Thank you Joe.

goodfore · January 23, 2017, 6:57am

HI @rsstephens,

The LCD Screen (901) seems to be working as intended. 902 doesn’t seem to do anything, but frankly, I don’t really know what that is being used for anyway, so not sure if we want to chase after this.

As for the text being displayed, it always has 00032 leading the text. Looking into the developer guide for it-100, it states that

The IT-100 sends this command whenever the text of the IT-100 menu changes
L
Line number (0-1) (30-31)
C1 - C2
Column Number (0-15) (30, 30 - 31, 35h)
D1 - D2
Number of characters to
display (1-32) ( 30, 31 - 33, 32h)
A1 - An
Ascii Data (size of D1, D2) - Ascii Da
ta may contain special
ASCII Chararacters 0-7

So the 00032 is line item, text size etc. Not sure if that provides any value. In my custom binding, I do a substring to cat those out.

data.substring(5);

I haven’t tried putting rules in place to process the LCD screen item yet.

Thanks,
Joe

rsstephens · January 23, 2017, 9:37am

Good to hear. Could be that there is no change for 902 so nothing is shown. I will leave as is for now. I appreciate you testing it. Thank you Joe.

ArC · August 3, 2017, 11:59am

Hi,

this might be old topic, however I have the following issue while sending the command. I want to “enable” zone to be bypassed when arming, so sending this command: sendCommand(SEND_DSC_ALARM_COMMAND, “070,,1,>,,#”)
070 - virt keyboard
and simulating keyboard press like: [] then [1], then [>] to select which zone and [] confirm to bypass.

all works whilst on the keyboard.

once OH2 rule triggers this - I get “System unavailable” on the LCD for 5-10 seconds and it turns zone into bypass mode.

wondering if I do something wrong here or I could somehow avoid this system unavailable message?

thank you

ArC · August 3, 2017, 12:04pm

…not sure why I cannot type “star” symbol…apologies

rsstephens · August 3, 2017, 12:41pm

Hello @ArC,

That is normal behavior for the DSC Alarm system. It will only allow one keypad to operate at a given time whilst all other keypads will show that message. You are basically simulating keystrokes from a virtual keypad, so all other keypads are locked out temporarily until the DSC Alarm system has finished processing the keystrokes. Hope this helps.

ArC · August 3, 2017, 12:58pm

Hi Stephens

thanks for a quick reply. I was wondering if not doing any harm to my system, but now understand it.

by the way, am just playing with the system and yet no good result. previous command seem has worked few times only, strange. however if I send: sendCommand(SEND_DSC_ALARM_COMMAND, “070,1”) it works, i.e. puts zone 1 into bypass mode and arms whole system right away. …and my intention only to “flag” zone to be bypassed upon next arm action.

any ideas how to solve this?

thanks in advance
Antanas

rsstephens · August 3, 2017, 2:19pm

Hello @ArC,

I’m not sure I understand all the commas in the original command. Have you tried:

sendCommand(SEND_DSC_ALARM_COMMAND, “070,*101#”)

where:

070 - keystroke command
, - command/data separator
* - function mode
1 - bypass mode function
01 - zone
# - return

Note that this will turn bypass mode on or off depending on which state the zone is currently in, assuming this works of course.

ArC · August 3, 2017, 3:04pm

Hi Stephens

when I run this command (for zone 1, or zone 01 or zone 19) I get the following:
events.log
2017-08-03 17:55:48.075 [ItemCommandEvent ] - Item ‘ZONE3_BYPASS_MODE’ received command ON
2017-08-03 17:55:48.083 [ItemStateChangedEvent ] - ZONE3_BYPASS_MODE changed from OFF to ON
2017-08-03 17:55:49.374 [ItemCommandEvent ] - Item ‘SEND_DSC_ALARM_COMMAND’ received command 070,*119#
2017-08-03 17:55:49.380 [ItemStateChangedEvent ] - SEND_DSC_ALARM_COMMAND changed from 070,# to 070,*119#
2017-08-03 17:55:49.380 [ItemStateChangedEvent ] - SEND_DSC_ALARM_COMMAND changed from 070,*119# to

openhab.log
2017-08-03 17:55:49.371 [ERROR] [rm.handler.DSCAlarmBaseBridgeHandler] - sendCommand(): ‘keystroke’ must be a single character string from 0 to 9, *, #, F, A, P, a to e, <, >, =, or ^, it was: *119#
2017-08-03 17:55:49.371 [ERROR] [rm.handler.DSCAlarmBaseBridgeHandler] - sendCommand(): Command ‘KeyStroke’ Not Sent - Invalid!

BUT when I use bit by bit, i.e.
when
Item ZONE3_BYPASS_MODE received command ON
then
//sendCommand(SEND_DSC_ALARM_COMMAND, “070,119#")
sendCommand(SEND_DSC_ALARM_COMMAND, "070,”)
sendCommand(SEND_DSC_ALARM_COMMAND, “070,1”)
sendCommand(SEND_DSC_ALARM_COMMAND, “070,>”)
sendCommand(SEND_DSC_ALARM_COMMAND, “070,>”)
sendCommand(SEND_DSC_ALARM_COMMAND, “070,>”)
sendCommand(SEND_DSC_ALARM_COMMAND, “070,>”)
sendCommand(SEND_DSC_ALARM_COMMAND, “070,>”)
sendCommand(SEND_DSC_ALARM_COMMAND, “070,>”)
sendCommand(SEND_DSC_ALARM_COMMAND, “070,>”)
sendCommand(SEND_DSC_ALARM_COMMAND, “070,>”)
sendCommand(SEND_DSC_ALARM_COMMAND, “070,>”)
sendCommand(SEND_DSC_ALARM_COMMAND, “070,>”)
sendCommand(SEND_DSC_ALARM_COMMAND, “070,>”)
sendCommand(SEND_DSC_ALARM_COMMAND, “070,>”)
sendCommand(SEND_DSC_ALARM_COMMAND, “070,>”)
sendCommand(SEND_DSC_ALARM_COMMAND, “070,>”)
sendCommand(SEND_DSC_ALARM_COMMAND, “070,>”)
sendCommand(SEND_DSC_ALARM_COMMAND, “070,>”)
sendCommand(SEND_DSC_ALARM_COMMAND, “070,>”)
sendCommand(SEND_DSC_ALARM_COMMAND, “070,>”)
sendCommand(SEND_DSC_ALARM_COMMAND, “070,>”)
sendCommand(SEND_DSC_ALARM_COMMAND, “070,9”)
sendCommand(SEND_DSC_ALARM_COMMAND, “070,*”)
sendCommand(SEND_DSC_ALARM_COMMAND, “070,#”)
end

it works
strange though.

nevertheless, system works at least with a longer solution.

rsstephens · August 3, 2017, 3:21pm

Hmm. Are you using the IT100 interface?

ArC · August 3, 2017, 3:23pm

yes, USB0 port.

:~$ cat /etc/openhab2/things/dscalarm.things
Bridge dscalarm:it100:MyBridgeName [ serialPort="/dev/ttyUSB0" ]
{
etc…