Hmm very odd- If I were you the next troubleshooting step I’d take is to use your command line and telnet into the evl (you’ll have to shut down hass while you do this- only 1 tpi connection is allowed at a time). I’d be curious if the evl drops the telnet connection too every so often. So if you telnet into it, and let it run for 30 minutes or so, to see if that dies too.
Thanks for the suggestion, I tested the telnet connection for over 12h now and not a single drop in connection. I also tried deleting my deps folder and restarted hass to have everything reinstall, but no luck in solving the issue.
There was 1 other person that looks to have a similar issue, but much less frequent.
Hi, I treid to get HA and EnviaLink (4) to work yesterday but were getting connection issues. I Found this thread and its my understanding that Envisalink only allows for 1 TPI User, so currently my Vera Edge is using the DSC Panel plugin and this now causes connection issues with HA + DSC integration. I read something in this thread about some proxy etc to resolve this, has there been any work considers to do this or if there is another way for me?
Can you connect HA to Vera with the component so that your don’t need envisalink to have two connections? Another possible solution is to not use Vera Edge and move everything to HA.
I was also having issues with getting ‘phantom’ zone status changes on my DSC system. Turned out to be related to the zonedump_interval as described previously. I ran into an issue when trying to disable them, however. Based on this:
Ok I was able to check this further, and yes I am indeed interpreting any result under 30 seconds as still open- exactly as you report.
I also was able to confirm the ability to turn off the zone timer dumps. Simply set your zone timer dump interval to 0, and that will stop them from running altogether.
I tried setting zonedump_interval: 0 however I got an error that the minimum value is 15.
Looks like based on the code (https://github.com/home-assistant/home-assistant/blob/dev/homeassistant/components/envisalink.py) that this is indeed the case:
vol.Optional(CONF_ZONEDUMP_INTERVAL,
default=DEFAULT_ZONEDUMP_INTERVAL):
vol.All(vol.Coerce(int), vol.Range(min=15)),
For now I set zonedump_interval: 31536000 (365 days), but it would be much cleaner if the zonedump was just disabled outright.
Cinntax, could this be addressed in an update?
EDIT: Oh forgot to mention I LOVE the Envisalink integration, thank you so much for all your hard work!
Hi Tim- certainly. I’m overdue for a release- I have a new pyenvisalink version to reference also- so I’ll get a pull request staged up over the next day or so. Thanks!!
Okay, I have just submitted a PR to remove the “minimum 15 second” requirement from the zonedump configuration parameter. I’ll let you know when it’s been accepted, and you can test in the dev branch.
FYI- my PR for bumping up the pyenvisalink version, as well as removing the 15 second minimum from the zonedump interval parameter has been accepted. You’re free to give it a shot from the dev branch! I gave my end a quick test or 2.
Just a note for anyone else besides me searching for this thread: DSC panels can also be integrated into HA using the Alarm Decoder module. ad2usb works great with HA and doesn’t use on any external servers for communication.
Are you using the AD2USB connected to Pi running HA?
I’m using ad2usb connected to an Ubuntu server but it shouldn’t matter. AlarmDecoder sells an “all in one” Pi as well so it works fine on the Pi. I’m actually using an Ademco panel but we tried it on a friends DSC before I installed it and it worked fine (and there are lots of DSC discussions in the AD forums). AlarmDecoder - Home Assistant
Thanks, just trying to find out if it can be used on the same Pi as HA and not have another Pi just for the AD2USB.
Sure. Just needs a USB port. You can always ask at the alarm decoder forum too, they’re good about responding.
I was reading this originally thinking the AD2 products were the same as the Envisalink ones but they aren’t. Envisalink is Ethernet and AlarmDecoder is USB.
I’ve noticed that when AC power is lost or a battery goes low in my system, either of them only report trouble: true within sensor.home_alarm_keypad. I have it set up to send a notification but can’t differentiate between whether my house has lost power or I just have a sensor with a battery going low.
Are ac_present: true and bat_trouble: false not supported (I never see them change - not sure if bat_trouble is for sensors or main backup battery) or do I not have something set up right? My config is the same as I wrote in post 385.
I took a quick look through the code, and we SHOULD be handling both ac_present and bat_trouble right now. On the DSC panels, when either of these things change, there should be an event sent to us (event code 802 and 803). In this context, both of those variables are at the panel level. not the zone level. I don’t have a DSC panel, but i guess i would expect a battery low on a sensor would be a zone fault, and it may trigger the trouble variable as well.
The next thing to check would be to put hass in debug log mode, and plug in/unplug your panel. You should see these events pretty much immediately if we’re getting them from your panel…
By the way, i do believe i pushed a code change to resolve that issue on 385- is that working better now?
How to get the debug events for the panel? I set my logger to debug level for everything
logger:
default: debug
And I get volumes of data for z-wave, sun sensor, etc., but the most I am getting for anything alarm panel related are INFO readings:
2018-01-12 17:55:59 INFO (MainThread) [homeassistant.components.envisalink] Envisalink sent a zone update event. Updating zones...
2018-01-12 17:55:59 INFO (MainThread) [homeassistant.components.envisalink] The envisalink sent a partition update eventSorry been busy the last few days. I’ll give it a try tonight. The pyenvisalink library uses the same logging mechanism as hass so I’d expect that to work. It’s been a while since I’ve done it though.
Okay- so I just put
logger:
In my config file, and I was able to get debug information from pyenvisalink.
2018-01-15 21:04:02 DEBUG (MainThread) [pyenvisalink.honeywell_client] {"alarm": false, "alarm_in_memory": false, "armed_away": false, "ac_present": true, "armed_bypass": false, "chime": false, "armed_zero_entry_delay": false, "alarm_fire_zone": false, "trouble": false, "bat_trouble": false, "ready": true, "fire": false, "armed_stay": false, "alpha": "****DISARMED**** Ready to Arm ", "beep": "off", "exit_delay": false, "entry_delay": false, "last_disarmed_by_user": "", "last_armed_by_user": ""}
In your case you’ll have the class be pyenvisalink.dsc_client.
I’ll admit it’s a little bit of a needle in the haystack.
Here’s another log example- this is raw data that the device is sending. You should see very similar input to this.
2018-01-15 21:04:02 DEBUG (MainThread) [pyenvisalink.envisalink_base_client] ----------------------------------------
2018-01-15 21:04:02 DEBUG (MainThread) [pyenvisalink.envisalink_base_client] RX < %00,01,1C08,08,00,****DISARMED**** Ready to Arm $