Comments/Testers to HC2 to DSC integration code wanted

[pos 22]

Hi

 

I was posting here earlier regarding HC2 integration with the DSC alarm. After tricky research with a lot of needed info missing and testing of the Fibaro alarm plugin, I decided to start to write my own integration code. No need to use the crappy EnvisaLink plugin in HC2.

 

I have used EnvisaLink 4 and used the API to it (95% is same as IT-100 API). You do not need to allow traffic to Internet från the EnvisaLink to Eyezon or so.

 

Just plug in the EnvisaLink, power it up and you are ready to go directly (well,  maybe change password..). The code is running in a virtual device. The code is working very well, has different debug levels and also has log to syslog implemented.

 

Scenes can use the “traps” from the alarm sensors through global variables. Extending it to read and write anything to/from the DSC alarm is very easy from here. I do however wonder if there is a better way than using global variables (that cannot be created from lua). I mean… there should be a way to directly talk between scenes and VD:s… But I haven’t found any…

 

 

Comments and feedback to the code is very much appreciated before I give the code its final touch… But don’t be to hard on me. I am rather new to Lua and HC2. And it is a beta after all that I have spent a day on… The API poll function is used to have control of the TCP socket. Documentation of the code is in the top of the lua file. Right now the code it is rather basic. I will implement buttons and writing to the alarm as well from scenes and also implement more stuff from the API. But as said... I would very much appreciate some feedback before I continue the work.

 

Please login or register to see this link.

 

Here are a few log output screenshots:

 

Please login or register to see this image.

 

 

 

 

 

 

Edited March 1, 2017 by pos

[smprofx 8]

1) I have tried to make a scene for STAY-ARM by sending code 031 instead of 033 but nothing happens (it doesn't arm and it doesn't show any debug error either. 

 

The STAY-ARM would need a different LUA code?

 

2) How would look a LUA scene for Panic Alarm so I could trigger the Outdoor sire in case of an event (flood / fire / other reasons while the DSC panel is disarmed)?

I see the code for panic is '060' but there are three modes available "Fire / Ambulance / Police" . Would it be possible to activate a particular panic mode ? (like Panic - Fire).

[pos 22]

9 minutes ago, smprofx said:

1) I have tried to make a scene for STAY-ARM by sending code 031 instead of 033 but nothing happens (it doesn't arm and it doesn't show any debug error either. 

 

The STAY-ARM would need a different LUA code?

 

2) How would look a LUA scene for Panic Alarm so I could trigger the Outdoor sire in case of an event (flood / fire / other reasons while the DSC panel is disarmed)?

I see the code for panic is '060' but there are three modes available "Fire / Ambulance / Police" . Would it be possible to activate a particular panic mode ? (like Panic - Fire).

 

Code 030 (Partition Arm Control ),  031 (Partition Arm Control – Stay Arm ) and 032 (Partition Arm Control – Zero Entry Delay) are all a non user pin activation. 

 

code 033 (Partition Arm Control – With Code) and 040 (Partition Disarm Control) requires a user pin sent

 

You must if you want to use 030, 031 or 032 remove the pin from your scene. For example

 

Change.:

local sendcode = sendcommand .. partition .. userpin

 

to:

local sendcode = sendcommand .. partition

 

 

Note though that I have not used these actively.

 

Question... Does everything else work?

 

Peo

[smprofx 8]

I've just made a scene with this LUA code:

--[[
%% properties
%% events
%% globals
--]]
local sendcommand = '031'
local partition = '1'
local sendcode = sendcommand .. partition
fibaro:call(510, "setProperty", "ui.INPUTCODE.value", sendcode)

 

Still nothing happens, the DSC Panel remains disarmed. 

 

Arming / Disarming / Triggering a scene using the DSC sensors seams to work fine. 

 

[pos 22]

1 minute ago, smprofx said:

I've just made a scene with this LUA code:

--[[
%% properties
%% events
%% globals
--]]
local sendcommand = '031'
local partition = '1'
local sendcode = sendcommand .. partition
fibaro:call(510, "setProperty", "ui.INPUTCODE.value", sendcode)

 

Still nothing happens, the DSC Panel remains disarmed. 

 

Arming / Disarming / Triggering a scene using the DSC sensors seams to work fine. 

 

 

Good everything else is working... Step one, CHECK !

 

 

I think you send the correct code for "stay arm". Maybe you have something configured in your alarm that prevents this. Increase debugging and check output of what the DSCengine pick up from from the alarm system bus. Maybe you cannot stay arm if the sensors see you (I have never used "stay arm"). I think you have to rad the DSC alarm manual. I think this is not something that can be solved from outside if the alarm system has something enforced that prevent this. If we send the correct code and it wont work, you have to check in the alarm itself.

 

But... start with increased debugging

 

Peo

 

 

2 minutes ago, pos said:

 

Good everything else is working... Step one, CHECK !

 

 

I think you send the correct code for "stay arm". Maybe you have something configured in your alarm that prevents this. Increase debugging and check output of what the DSCengine pick up from from the alarm system bus. Maybe you cannot stay arm if the sensors see you (I have never used "stay arm"). I think you have to rad the DSC alarm manual. I think this is not something that can be solved from outside if the alarm system has something enforced that prevent this. If we send the correct code and it wont work, you have to check in the alarm itself.

 

But... start with increased debugging

 

Peo

 

 

 

From DSC manual:

 

2.2  Stay Arming

The Ready light must be ON to arm the system. If the Ready light is OFF, ensure that all protected doors and windows are secure or bypassed.  

 

Peo

[smprofx 8]

This is what I got from the debug:

 

[DEBUG] 00:31:19: Session start
[DEBUG] 00:31:19: DSC alarm IP: 192.168.1.151 DSC alarm TCP/IP PORT: 4025
[DEBUG] 00:31:19: Contacting server...
[DEBUG] 00:31:19: Request for password, sent after socket setup # API CODE:5053CD
[DEBUG] 00:31:19: checksum is: 1C
[DEBUG] 00:31:19: Password sent
[DEBUG] 00:31:19: Login interaction - Password Correct, session established # API CODE:5000052A 5051CB
[DEBUG] 00:31:30: Print all data requested. New code received: 50000025
[DEBUG] 00:31:30: Poll response received - TCP session to EnvisaLink is active. Good...
[DEBUG] 00:31:52: Partion Arm Control - Stay ARM - Partition: !!! NOT IMPLEMENTED !!!1
[DEBUG] 00:31:52: As expected - Arming/Disarming code wiped out from memory after execution!
[DEBUG] 00:32:03: Print all data requested. New code received: 50000025
[DEBUG] 00:32:03: Poll response received - TCP session to EnvisaLink is active. Good...
[DEBUG] 00:32:04: Waiting 1 ...
[DEBUG] 00:32:05: Waiting 2 ...

 

I'm doing this implementation remotely so nobody is at the house where DSC is installed to trip a sensor. All sensors are safe. 

However I cannot check now if the Red light is ON or OFF. Will do a in person check tomorrow. 

Edited April 20, 2017 by smprofx

[pos 22]

He he... I can see I have not implemented that

 

--snip--

[DEBUG] 00:31:52: Partion Arm Control - Stay ARM - Partition: !!! NOT IMPLEMENTED !!!1

--snip--

 

 

But if you want a second I can check it up

 

Peo

Around row 333 to 350 or so... Change your existing section to this... Then STAY ARM SHOULD WORK. THE OTHER two will be added during the week into a 1.9...

 

  elseif string.match(z, '^031') then -- Partion Arm Control - Stay ARM
    local part
    part = string.sub(z, 4, 4) -- Get current partition
    if DEBUG >= 1 then fibaro:debug('Partion Arm Control - Stay ARM - Partition: ' .. part) end
    if SYSLOG == 1 then syslogserver('Partion Arm Control - Stay ARM - Partition: ' .. part) end
    -- SEND  CODE
      local checksum = DSCchecksum(z)
      local sendcode = z .. checksum
      local a, b = tcpSocket:write(sendcode .. '\r\n')
      if a > 0 then
        if DEBUG >= 1 then fibaro:debug('Code sent') end
        if SYSLOG == 1 then syslogserver('Code sent') end
      else
        if DEBUG >= 1 then fibaro:debug('Something is wrong with the code or the checksum calculation. A bug?') end
        if SYSLOG == 1 then syslogserver('Something is wrong with the code or the checksum calculation. A bug?') end
      end
      fibaro:call(LOCALDEVICEID, "setProperty", "ui.INPUTCODE.value", "NULL")
    -- SEND  CODE

 

NOT CHANGE THE BELOW... THIS IS TO NOTE WHERE THE ABOVE BLOCK ENDS...
  elseif string.match(z, '^032') then -- Partion arm control - Zero entry delay
    -- NOT YET FULLY IMPLEMENTED. TO BE DONE !

[pos 22]

Please login or register to see this code.

 

The code, release notes and the more detailed docs are here:

Please login or register to see this link.

 

Peo

[smprofx 8]

Hi Pos!

 

I have tested the new 1.10 version and it works flawlessly so far!

The added PANIC modes are really handy and works correctly.

I have made three scenes, one for each panic mode (Fire, Auxiliary / Medical , Burglar).

For Fire panic the alarm triggers the DSC outdoors siren in pulse mode (play short alarm sounds)

For Auxiliary / Medical the alarm triggers only the DSC keypad beeps and can dial a set phone number (medical / family ...)  letting them know that a situation occur. 

For Burglar the alarm triggers the outdoors siren continuously as a normal alarm would do. 

 

Using this functions I can now create various scenes that would make use this like for example when a flood / fire is detected by one of the Fibaro HC connected sensors and I'm in the backyard the Fire panic alarm is automatically triggered and I'm acoustically made aware of the event in case I don't have the phone near me or the push notification doesn't work correctly (happens once in a while .. ) 

 

Also using the variable ArmedStatus I have created a simple scene that turns a RGBW led strip from my ceiling into RED when house first-floor is fully armed and I'm upstairs, orange when stay-armed (only outdoor proximity sensors armed) and white when system is disarmed so I know the alarm status without looking for keypad or other devices

 

Well in seams that this VD opens a lot of possibilities to integrated in both directions the Fibaro with DSC Panel.

 

My congrats to you for doing a great job and hopefully you will continue to develop this VD by adding more features. (intuitive / customization zone names for LUA / Block scene editors, individual VD for DSC connected sensor to be able to allocate each DSC VD sensor into corresponding rooms for intuitive management, night arm mode ... this are just a few  ideas

 

 

 

 

[pos 22]

Thanks 

 

 

B t w... I discovered a corner case where you could sit with a arming status that is not correct compared to the DSC unit. A few scenarios can occur where it is simply impossible to know the DSC unit status. That is after a restart of HC2, a re-save of the lua code in the VD, network errors, DSC unit or Envisalink reboot. Status change can occur wile not connected to EnvisaLink even if the time is short... This will probably not be a problem. But with 1.11 an "unknown" status is reflected both for the scene triggers as well as the Fibaro app presenting device. Note that the DSCengine VD will try to reconnect to the EnvisaLink if the connection is lost due to any of the above. But even so.... it is not possible to write code and ask the DSC unit of the current status when reconnecting. A status change (i.e a DSC event) must occur before the "unknown" status is changed to something else (i.e ARMED AWAY, ARMED STAY, ARMED ZERO-ENTRY-AWAY, ARMED ZERO-ENTRY-STAY or DISARMED)

 

 

As before, te updates are here:

Please login or register to see this code.

 

The code, release notes and the more detailed docs are here:

Please login or register to see this link.

 

Peo

[pos 22]

I have now updated to version 1.12

 

Now the setup process is easier than ever... As of 1.12 all needed global HC2 variables are auto created. And if you later on add zones or partitions to the DSC alarm, the code will auto create what it needs (auto creation can of course be disabled as well).

 

So now the process to integrate your DSC alarm with your Hc2 is as easy as..

1 Add two VDs + three labels

2 Edit the lua code variables (ids, password, envisalink IP etc)

3 paste code inte VD

DONE

 

The code is in the same place as mentioned in earlier posts

 

As it is now, the DSC <-> HC2 integration fills my own needs. If any of you that uses it have feature ideas, please post them....

 

Peo

[pos 22]

Hi all

 

I have now made release 1.15 available of the DSC <-> HC2 alarm integration

 

As of this version all global variables as well as presentation VD + its labels are automatically created. the setup is therefor as easy as...

 

# 1 - Create a VD named DSCengine + a label and ID on it named INPUTCODE

# 2 - Edit the lua 1.15 codes variables at the top of the code to suite your need

# 3 - Paste the code inte the DSCengine VD main section and click save

DONE

 

Other new  features is to detect AC power failure in the house among other things...

 

As before, the updates are here:

Please login or register to see this code.

 

The code, release notes and the more detailed docs are here:

Please login or register to see this link.

 

Feedback very much appreciated

 

Peo

[smprofx 8]

Hi Peo!

 

I've just checked the new code at it works correctly.

I have deleted the old DSCpresenter, updated the DSCengine with the new code and saved.

The DSCpresenter is correctly autocreated in this new version.

 

 

[devfern24 10]

Hi @pos,

 

I finally had a chance to try this code and I have to say... Great Job!!  I adapted your original code to run in a single VD (instead of the engine + presenter) and added a few buttons in it to handle arm/disarm. This is a much better solution than what I had been using before (Vera + API) and goes to show why this community NEEDS user plugins ASAP to make Fibaro a truly viable home automation solution.

 

Great work and thanks for sharing! Here is a screenshot of my adaptation:

 

Please login or register to see this attachment.

[pos 22]

Hi @devfern24

 

Tnx... I am glad you like it. The understanding of checksum calculation in the API as well as the TCP/IP socket handling took some time...

 

I mention in the docs why I did not use buttons in a VD for arm and disarm. This is for security reasons as VDs can´t be protected by a pin. Therefor I have instead pushed for and also have examples of how to use arm and disarm with a scene protected by a pin. But it is of course up to the user. All users does not have security paranoia as me...  And the reason for using a separate device for presentation is also security. I wanted the engine itself be just a like an engine/service to which no user need or shall have access to. And the presentation device is in later releases automatically created and set up. So there is no need for manual creation of it.

 

I can see the INPUTCODE field. Do you use it? If you do all in the same device, you do not need it. That field was ment for DSC arm/disarm codes in transit from the user input (from a scene). And when the code is sent on to the DSC alarm, the field is immediatley "NULL"ed to have an as short as possible time frame where the code can be seen in the VD.  And the reason for putting this field on the DSCengine device was because no user should have access to the DSCengine/service device as it was designed.

 

So, to sum up.... I try to keep the security as high as possible with the tools Fibaro provides...

 

You do not build on my latest release 1.16 as I cannot see an extra battery status field that was implemented in 1.16. What release do you build on? Do you use a release where I auto create all global variables and VD?

 

 

Other things on the todo list for future releases are:

- More features to present, and in parallell also auto create their corresponding global variables to trigger on.

- show icons in the presenter device instead of text

- add breached/restore info in the presenter device for all zones

- Auto create trigger variables for the zones with their friendly names so it will be easier to use

- add as option to have arm/disarm buttons in the presenter device. I.e show these buttons if a enable variable is set in the DSC engine variable section. This  is like you have done already  But I will not show the buttons by default

 

 

Must mention I have had great help by @smprofx for testing and feedback.

 

 

You have done a nice layout. I would very much appreciate input from you of how to put an icon in the result field instead of text. I would be glad if you could  PM we with some code snippets. Because this is on my todo list for later releases....

 

Peo

 

 

 

 

[devfern24 10]

3 minutes ago, pos said:

I mention in the docs why I did not use buttons in a VD for arm and disarm. This is for security reasons as VDs can´t be protected by a pin. Therefor I have instead pushed for and also have examples of how to use arm and disarm with a scene protected by a pin. But it is of course up to the user. All users does not have security paranoia as me...  And the reason for using a separate device for presentation is also security. I wanted the engine itself be just a like an engine/service to which no user need or shall have access to. And the presentation device is in later releases automatically created and set up. So there is no need for manual creation of it.

 

For myself, I am not too worried about password protection of arm/disarm because my phone is password protected. But I do understand your concern and others may feel that way as well.

 

9 minutes ago, pos said:

I can see the INPUTCODE field. Do you use it? If you do all in the same device, you do not need it. That field was ment for DSC arm/disarm codes in transit from the user input (from a scene). And when the code is sent on to the DSC alarm, the field is immediatley "NULL"ed to have an as short as possible time frame where the code can be seen in the VD.  And the reason for putting this field on the DSCengine device was because no user should have access to the DSCengine/service device as it was designed.

 

I was going to ask you about this. I tried messing with the code in my arm/disarm buttons to send the TCP commands to EVL themselves, with no success. I was receiving strange responses from EVL, although checksum values were the same as if I was using the code in main loop. For now I have just used to buttons change the INPUTCODE label and kept your original programming, although I have notcied there is sometimes up to a 10s delay between the INPUTCODE label changing and the execution of the command. Any ideas how to send commands to EVL directly from the buttons?

 

14 minutes ago, pos said:

You do not build on my latest release 1.16 as I cannot see an extra battery status field that was implemented in 1.16. What release do you build on? Do you use a release where I auto create all global variables and VD?

 

It appears I have built around 1.15... that was the most recent one when I downloaded.

 

16 minutes ago, pos said:

You have done a nice layout. I would very much appreciate input from you of how to put an icon in the result field instead of text. I would be glad if you could  PM we with some code snippets. Because this is on my todo list for later releases....

 

Icons can be added to labels/ buttons simply by copying and pasting them from here: 

Please login or register to see this link.

 

Nothing fancy going on there! haha

 

Nice work guys!

[smprofx 8]

@devfern24 Nice presentation VD!

 

Does the green icons turns red when a sensor is breached? 

 

It would be interesting to dipaly also the timestamp for each sensor and the name of the user / code which performed last status change (arm / disarm ... ) and also to display the events like time when an alarm was activated and the sensor which tripped it ... Oddy, my DSC keypad doesn't diplay events history with tripped sensors and timestamp .... so a such feature would be more than welcomed! 

[pos 22]

@devfern24

 

Increase debug level to 5 and check the log, then you will see where the delay is.... The "lag" is  in the "listen" function loop. I think the max delay is about 13s (delay times + execution time in the main loop). It is possible to decrease the listen loop counter. But make sure you know what you are doing... The socket handling is stable. But even so, I will probably rewrite the socket to non blocking later that will decrease this time a lot. But it cannot be 0s as there is execution time in the main loop. Note that there are programming limitations writing code for a VD. I wanted to write a real Fibaro plugin, but Fibaro tech stuff said that they would not allow that at the moment, but did not tell why...

 

But personally I do not see this as a problem as the triggers are instant anyway (the listen loop will not count to end if it sees an event). Only the arming and disarming process through INPUTCODE label is delayed if there are no other events so the listen loop must first end before picking up the code.

 

 

Indeed it was easy with the icons...

 

Peo

 

 

@smprofx

 

 

I can add breach and restore times of the zones. That is easy. But I think showing timestamps should be an enable/disable flag to decide for each user to show. The reason is that all stuff added in main loop eats execution time. When you are away there should not be a problem. But when the family is at home and you have wired PIRs with a restore time of maybe 3s, there could be a lot of timestamp calculations. A person just going around in one room can eventually breach/restore a single PIR every 3s. And each breach and restore would trigger time calculations.

 

When it comes to the user trigger the arm or disarm. That is already in the code (in the DSC_P<n>_OpenClosing global variable) and can be used as scene triggers. There are examples of that as well. It is just to print it out in the presentation view. Good input from you. Will att that...

 

Peo

Edited May 7, 2017 by pos

[devfern24 10]

3 hours ago, smprofx said:

Does the green icons turns red when a sensor is breached? 

 

Yup, it changes to a red "X" when sensor is breached

[devfern24 10]

@smprofx @pos

 

Any idea how I could make my arm/disarm buttons send TCP commands directly to EVL4? I tried to copy the code from the armdisarm() function (and modify to only encompass that particular button) as well as the required checksum and DecToBase functions but I had no success. The checksum was the same value for the command as in the original main loop code, and it sent ok using tcpSocket:write, but I got some sort of "unkown response" returned from EVL when I checked the main loop debug after pressing the button. Hopefully that all made sense... any ideas?

 

Also, I love the auto creation of global variables. I have not played around too much with the fibaro API from within the HC2 itself. Can you point me in the right direction for autocreating GVs from a LUA scene, not from a VD? Would be very useful for some of my scenes.

 

Thanks Fellas!

[smprofx 8]

@devfern24 I belive pos can help you with the needed code. I'm only helping him to test new release versions as my coding skills tend to "0"