I have an envisalink 4 with no other software other than homeassistant. I wrote a custom component that utilized the DSC motion sensors and ran into the double-trip behavior as well. I figured it was perhaps some timing race condition in homeassistant. For alarm situations a double-trip doesn’t hurt anything as far as I can tell but it was annoying to have to code around it.
@danbutter @micque I had similar DSC behavior and cinntax had some theories on it that led me to try zonedump_interval: 64000 in my config which solved my issue. I believe he put something in a later release to try to fix it permanently, but I’ve left my zonedump interval with the large number. Anyway, it might be worth trying.
1 Like
I don’t even have that configured, but looking at the docs it says you don’t need it for DSC.
With my extra layer and repeater I guess I don’t need the keep alive either.
I’m not sure how waiting a long time to dump status will help. If anything it seems like it would just delay the issue.
I wish I knew how to debug this better to try and figure out why it happens in the first place.
I’ll play with it and see if I can figure anything out.
Just an FYI for everyone- my pull request was accepted into the development branch. I ended up extending the existing connection retry logic into the initialization sequence. So at this point, regardless of when a connectivity error occurs, I’ll always attempt to recover.
1 Like
Thanks for your response regarding the zonedump_interval. After rereading the documentation, I decided to remove it from my settings (probably shouldn’t have had it in there to begin with). This cleared up the issue for me.
1 Like
Hello,
Running: Hass.io 0.100.2
I also use the dscserver (hosted on windows). Last night home assistant lost the connection and did not reconnect until I restarted HA. I unfortunately did not capture the log but it seems like a similar situation to rhatguy.
I did get an alert from envisalink stating that the tpi connection was reconnected. My best guess is that dscserver lost the connection for whatever reason, reconnected but home assistant did not. I have a node-red instance using the node-red-contrib-envisalink via dscserver and it was connected in the morning, so it must be related to home assistant in some way.
I did some testing, after manually restarting dscserver, homeassistant reconnected as expected. I will be keeping a closer eye on the logs from now on. This setup has been 100% stable for over 6 months until now. Not sure what changed, or if its just a fluke.
Are there any local integration options for the Neo series?
No, as I know.
@Cinntax
Hi, when a PGM-output is sent, the DSC panel generates code 660 which is not configured in this integration. Is it possible to add this as a state change? Need it to use the alarm remote control for garage port opener where I’ve configured one of the buttons as PGM_output. This would be my signal IN to HA.
Looks this way in the log today when I press my remote control button:
#2020-09-23 23:05:02 DEBUG (MainThread) [pyenvisalink.envisalink_base_client] RX < 6601CD
#2020-09-23 23:05:02 DEBUG (MainThread) [pyenvisalink.envisalink_base_client] No handler configured for evl command.
Hello, I have one dumb question: DSC has a proprietary software which works over local network communication. I’m wondering if that could be a way to develop an integration without the need for a third party hardware. I’m surely not discovering anything new but would like to understand if that could possibly an option at all. Thanks.
Hey @Cinntax, the envisalink integration has been working great for me for quite a while now. One thing I noticed and another user @autumnwalker documented here, is that after HA restarts the time displayed on the DSC keypads is UTC until the EVL does it’s own sync at 3am.
This is a pretty minor issue but wondering if you know of a fix. I’d be fine with running an automation at every HA startup to force a time update if that is a possibility.
Thanks
Hello again!! DSC seems to have been acquired by tyco. I’ve come to know this by checking for the current app for managing it in the App Store (http://dsc.com/connect-alarm/#). The migration path that I’ve found for my DSC firmware (and most of yours here I suspect) feels all but DIY.
I wonder if the above changes anything in terms of the need of additional 3rd party hardware; maybe the new firmware exposes some sort of local API?
Anybody can comment?
Thanks,
Hello everyone,
I actually just changed houses, and am just now finally getting things back where I can actually “do” home-assistant again.
In terms of a more “direct” integration with the alarm panel, I’ve heard people having success with the alarm decoder project:
http://www.alarmdecoder.com/
Both this, and the evl devices emulate another keypad, however the evl offers a higher level interface (which may be good or bad).
Ok- so the time thing I actually did make an attempt to fix back in February of 2019. Unfortunately it’s difficult for me to test it, as there’s not the same setting on the honeywell panel. It was released in pyenvisalink v3.9, and should already be in home-assistant (it appears to be using version 4).
The way it’s supposed to work is- as soon as home-assistant connects to the envisalink for the first time, right after it logs in i send a command ‘010’ to set the time to the server’s time. https://github.com/Cinntax/pyenvisalink/blob/949026cd689d4026e4aa7e41a3d3c2a7a11f54da/pyenvisalink/dsc_client.py#L126
Hey Kitus-
So i think it’s more complex than that- DSC was acquired by Tyco, and (at least part of) Tyco was acquired by Johnson Controls.
The short version here is that i dont think anything will change with your integration options here.
Everything i’m seeing on the documentation sent in your message applies to the DSC NEO series, which uses an encrypted communications protocol over the wire to a given keypad- so that’s why the envisalink doesn’t work with it.
If they eventually provide an API that can be developed against, then you still need something like an envisalink or alarmdecoder that will need to implement that low level API and expose it to 3rd parties like us. So if this new firmware does open the door on the DSC side, it’s unfortunately only step 1 to a full integration.
Hi @Danne82,
We can certainly do this- however I have had problems in the past with implementing these very specific DSC things in home-assistant using the “alarm panel” component - it’s just because there are generic services and actions that ALL of the planel components have (arm/disarm/keypad update etc) that this doesn’t really fall into. There was a similar issue getting arm_night mode going (I didn’t contribute that piece). Not saying it’s impossible, but maybe a bit difficult- i can also understand wanting consistency in the HA platform.
One path of least resistance might be to simply have a keypad status attribute called “last_pgm_triggered”, and when you trigger the PGM i can update it with the current time, and send a generic keypad update- would that be something you could automate off of?
I have the same goals as Danne82. I have my DSC keyfob setup for a PGM functions and would like to trigger HA stuff with it. It seems like if alarm panel had a value for PGM last triggered and which PGM that would work.
Love the Envisalink integration. I have a wired DSC door switch going to garage and I use it turn on garage light when open and off when closed with an automation. For some reason, when I close the door the light will go off then come back on after a few seconds then go back off after a few seconds. I tried putting a 1 second off to on the Trigger but that didn’t help.
ok
one thing
how can i find it in my HA? is it a … what is it?
If you are looking for Envisalink, and have the Envisalink interface card you will need to add it to Home Assistant as described here https://www.home-assistant.io/integrations/envisalink/
Hey @Cinntax! I can confirm that I’m running the current version of HA 2020.12.01 and this is issue is still occurring.
Is there a reason we need to send the 010 command? EVL is staying on time based on the EVL NTP.