I haven’t tried the dev branch so haven’t put this in use yet. When will this go to production and/or can you give me some direction on how to switch to dev?
Awesome. I had not upgraded to .23 yet so once I did, the configuration waiting patiently in my yaml files initiated and everything looks great!
Great to hear it!! I’ve been working on other house projects recently, so I haven’t worked on any improvements (there were a few things mentioned here)- but I’ll be sure to post on here again when I do.
Thank you for that- I think the 510,511,840,841 would be good to actually implement. For 673, i’m actually not sure what that’s for, and I was handling 700 there for a while, but as I recall 700 always come alongside one of the other “close” codes, so it’s not really buying us anything either.
Great! 
Can you please check if its possible to pass data to home alarm keypad.
As for 673,700,701,702 i suggest to only ignore/drop for now, so they aren’t filling upp the error logg.
What kind of data are you wanting to pass? The pyenvisalink library does support passing arbitrary keypresses- but right now in HA we’re only passing data to support arming/disarming the alarm. I suppose i could expose a service to pass that through…
I was thinking of this that is automatically added when adding envisalink in configuration and never change
Cinntax,
I think it would be great to activate an actual alarm - a bit like the panic button on the keypad, similarly it would be good to actual deactivate the alarm whilst it is sounding from Home Assistant if for example we know it to be a false alarm.
For the disarm request- can you not already do that? I can currently send a disarm command on my honeywell panel, and it will disarm even if the alarm is sounding.
For the panic/manual alarm trigger- we can certainly do that (i’d probably just expose a service you can call as a response to some other conditions).
I’m hoping to spend a little bit of time on this this weekend.
Sorry - you are probably right about the disarm command - I have to be honest and admit I haven’t actually tested that! Will try setting the alarm off and using the disarm command this weekend.
Good luck about the panic button/trigger idea - let me know if I can be of any assitance.
Does anybody else have issues using this with a DSC panel and irregular HASS startup?
With envisalink enabled it’s a roll of the dice as to whether all my other sensor and binary_sensor devices get initialed on start, as soon as I remove the envisalink component everything always loads up fine.
I’ve tried to do some troubleshooting, but the only thing that seems repeatable is that when things don’t load envisalink state change entries are the first thing in the log before anything else. Maybe we need a slight delay after connecting before forcing an update of the states?
Hmm… i personally can’t say that i have had issues with this. What version of HASS are you running? I admit i’m a version or 2 behind right now.
I haven’t tried to disable envisalink but I do have variable success getting weather to load on startup. About a 50/50 chance. A restart or 2 usually fixes it. I’ll try disabling envisalink to see if I have more luck. I am up to date. 26.2.
I understand the envisalink lets you send commands to the alarm panel (like arm/disarm). Can it also send events?
For example if I have a Z-wave door sensor connected to HASS, can HASS forward its events to the alarm system?
Thank you!
Hi all,
I got this working with my EV3 it seems, but some things are wonky, like if I press Disarm it pops up with a spot to enter a code but you can’t actually type in it. I have more zones than this but tried just 1 as a test, here’s what I have in the configuration.yaml (it’s spaced properly on mine but not sure how to paste code:
DSC Alarm
envisalink:
host: 192.168.1.33
panel_type: DSC
user_name: user
password: user
code: ‘1234’
zones:
01:
name: Front Door
type: opening
partitions:
1:
name: DSC Alarm
But my log shows non stop this:
16-08-19 08:19:14 pyenvisalink.envisalink_base_client: No handler configured for evl command.
16-08-19 08:19:14 pyenvisalink.envisalink_base_client: No callback configured for evl command.
16-08-19 08:19:14 pyenvisalink.dsc_client: No handler defined in config for 08:, skipping…
16-08-19 08:19:14 pyenvisalink.envisalink_base_client: No handler configured for evl command.
16-08-19 08:19:14 pyenvisalink.envisalink_base_client: No callback configured for evl command.
16-08-19 08:19:14 pyenvisalink.dsc_client: No handler defined in config for 08:, skipping…
16-08-19 08:19:14 pyenvisalink.envisalink_base_client: No handler configured for evl command.
16-08-19 08:19:14 pyenvisalink.envisalink_base_client: No callback configured for evl command.
16-08-19 08:19:14 pyenvisalink.dsc_client: No handler defined in config for 08:, skipping…
16-08-19 08:19:14 pyenvisalink.envisalink_base_client: No handler configured for evl command.
16-08-19 08:19:14 pyenvisalink.envisalink_base_client: No callback configured for evl command.
Any suggestions?
Not at this time- no. Note that it’s not possible to perfectly integrate this sort of thing, as the alarm panels themselves really rely on their own sensors to trigger the alarm (which evl3 is not). It would be like having your keypad act as a zone.
The current proposed solution for the next release would be to give the ability to trigger a panic alarm from HASS, so you could at least catch an event from zwave, and do some logic around it to trigger the actual alarm in response.
I think the only full integration in that way from HASS would be to put together a controllable switch that you actually hard-wire into your panel as a zone, and then HASS could trigger that to simulate zone closure.
Hmm… very odd- I don’t see anything terribly off in your config. The only difference i see between yours and mine is that i have wrapped my names (like DSC Alarm/Front Door) with single quotes.
Other than that- one other consideration is- which envisalink device do you have? evl3 or evl4? Both are supported, but there is a config variable you have to set. evl3 is default.
Those messages you’re seeing- while I don’t expect to see so many of them, are somewhat normal. Basically what’s happening is- the DSC sends a LOT of events, some of which we don’t really care about- so those messages are just saying that the DSC sent an event that we haven’t handled, so it’s ignoring it.
Other posters here have requested that I handle a few more events in the next release, and when i do that, those will be fewer- and also looking at changing the log level to clear that up too.
In terms of the next release, it’s been in the works for a while now. I have most of it done, but was distracted by a mysensors project i’m also working on.
Great thanks, it’s the EVL3. Like I said it seems to work, when I open the front door the HA portal updates after a few seconds. Seems to take longer to update when I close the door but not a huge deal. I haven’t really played around with the alarm stuff on HA too much yet, was busy getting lights and what not working.
I feel like this may not even be possible anyway, but the way I had it with HomeSeer was I’d do programs like:
-
If Z-Wave Schlage door lock is unlocked from the outside by the keypad with user code 1, then disarm DSC alarm.
-
If Z-Wave Schlage door lock is locked from the outside by the keypad, then arm DSC alarm.
But my locks go through the Wink Hub and seem to just be on/off devices in HA, so I don’t know if it’s even possible to have HA run a program like that since I don’t think you can differentiate between how a lock was locked/unlocked, vs just being one or the other.
I see. Thanks!