Oops that last post those errors were from a different version.
Okay I think i see what’s going on with the “false” thing. What partition number are you adding into your configuration.yaml? I ask because i was looking through some test results, and the evl3 actually supports up to 8 partitions, and if we never get information back on a given partition, the initial state of “alpha” is false. So my thought is that sensor there in the screenshot is reporting on a partition that you’re not using.
Cinntax. I have the partition listed as follows in my yaml:
partitions:
1:
name: 'Home Alarm'
This should be right for my alarm as I only have one partition set up (as far as I know - could check the programming to be sure).
I’m also experiencing this exact issue. My other binary_sensors almost never show up when envisalink is enabled. Any ideas?
I’m usually able to get everything working after a couple of HASS restarts. It’s gotten better on the latest dev versions, but still happens occasionally for me. I had thought it was sensor related, but I’m starting to think it has more to do with mqtt since all the ones that fail to load are always mqtt sensors.
Kind of sounds like some sort of critical race condition. The envisalink component is running in a background thread so that it doesn’t conflict with anything else, but maybe there’s still some conflict somewhere.
Just wanted to provide some feedback:
1.) I figured out my inability to arm my alarm - I didn’t have option 015 of the DSC programming for Quick Codeless enabled so the Envisalink was requesting a code.
2.) The Home Alarm Keypad entity that was showing mostly false occasionally correctly shows ‘Ready’ but for the most part its just says False for all the different parts. I was browsing through the dsc_client and honeywell_client from PyEnvisalinkand noticed that this whole section is not in the dsc_client:
def handle_keypad_update(self, code, data):
“”“Handle the response to when the envisalink sends keypad updates our way.”“”
dataList = data.split(‘,’)
# make sure data is in format we expect, current TPI seems to send bad data every so ofen
#TODO: Make this a regex…
if len(dataList) != 5 or “%” in data:
_LOGGER.error(“Data format invalid from Envisalink, ignoring…”)
return
partitionNumber = int(dataList[0]) flags = IconLED_Flags() flags.asShort = int(dataList[1], 16) beep = evl_Virtual_Keypad_How_To_Beep.get(dataList[3], 'unknown') alpha = dataList[4] _LOGGER.debug("Updating our local alarm state...") self._alarmPanel.alarm_state['partition'][partitionNumber]['status'].update({'alarm': bool(flags.alarm), 'alarm_in_memory': bool(flags.alarm_in_memory), 'armed_away': bool(flags.armed_away), 'ac_present': bool(flags.ac_present), 'armed_bypass': bool(flags.bypass), 'chime': bool(flags.chime), 'armed_zero_entry_delay': bool(flags.armed_zero_entry_delay), 'alarm_fire_zone': bool(flags.alarm_fire_zone), 'trouble': bool(flags.system_trouble), 'ready': bool(flags.ready), 'fire': bool(flags.fire), 'armed_stay': bool(flags.armed_stay), 'alpha': alpha, 'beep': beep, }) _LOGGER.debug(json.dumps(self._alarmPanel.alarm_state['partition'][partitionNumber]['status']))
I wondered if this affected the fact the ‘falses’?
Ahh man- i just missed it. I’m about to check in a change that will make us respond to the “900” request for a code. :). Anyway, yeah the difference with the honeywell is that it automatically sends a keypad update every 10 seconds or so. The equivalent on the DSC side is the 510/511 statuses. I was thinking about implementing those, but thought some of this other stuff was higher priority. However now that i know that the status DOES come through, and is overridden- that helps, I can keep looking.
I think what may also be happening is- when we first initialize everything, the “alpha” value is false, and never updates until we get a proper event for it. So it may be that if your trouble LED is on (and we’re not as of yet handling that status)- we might not be getting the events always that we need to.
So I’m going to see if I can capture more of these events, and also default the alpha status to “N/A” instead of false- that way it’s a string value, and a little easier to determine where it came from.
Okay- I’ve pushed a new version to my branch, with corresponding version of pyenvisalink- version 1.5
https://github.com/Cinntax/home-assistant/tree/panic
Here’s what has changed:
-
Now should be responding to event 900, so if the DSC challenges us to give the code upon arming, it will send the code you put into the UI.
-
Now responding to a bunch of new events- including 626, which I think was causing an issue when @privatesam was testing the panic feature earlier. I also think that some of the other statuses should show too, like chime, ac_present, etc.
I’m now being pretty verbose with the “alpha” field in the status (that’s the part that shows up in the sensor status)- so I don’t think it should stay at “False” anymore. I’m a little nervous it’s going to be constantly changing, but please let me know how it goes.
I’ll do a little more testing with more binary sensors to see if there are conflicts with this component, but i haven’t changed anything there.
FYI- i was able to reproduce the issue that mezz64 and dcshoes23 posted about. I reproduced this by adding a simple command-line binary sensor. On occasion this sensor would fail to show up at all.
Unfortunately the cause is a bit unknown at the moment- it does appear that in times when it does load, that it loads prior to the envisalink binary_sensors loading.
One thing I’m going to look at is- I’m using a new way of discovering/loading up components, which was released around 0.22 or so. I do wonder if maybe that’s in conflict with the old way.
Thanks so much for looking into this issue and for all of your hard work so far, I really appreciate it and think that you’re doing some amazing work!
I am trying to get my Envisalink up and running with Home Assistant. When I try to upgrade the package (pip3 install pyenvisalink --upgrade), I get the following errors:
Collecting pyenvisalink
Installing collected packages: pyenvisalink
Exception:
Traceback (most recent call last):
File “/usr/local/lib/python3.4/dist-packages/pip/basecommand.py”, line 215, in main
status = self.run(options, args)
File “/usr/local/lib/python3.4/dist-packages/pip/commands/install.py”, line 317, in run
prefix=options.prefix_path,
File “/usr/local/lib/python3.4/dist-packages/pip/req/req_set.py”, line 742, in install
**kwargs
File “/usr/local/lib/python3.4/dist-packages/pip/req/req_install.py”, line 831, in install
self.move_wheel_files(self.source_dir, root=root, prefix=prefix)
File “/usr/local/lib/python3.4/dist-packages/pip/req/req_install.py”, line 1032, in move_wheel_files
isolated=self.isolated,
File “/usr/local/lib/python3.4/dist-packages/pip/wheel.py”, line 346, in move_wheel_files
clobber(source, lib_dir, True)
File “/usr/local/lib/python3.4/dist-packages/pip/wheel.py”, line 317, in clobber
ensure_dir(destdir)
File “/usr/local/lib/python3.4/dist-packages/pip/utils/init.py”, line 83, in ensure_dir
os.makedirs(path)
File “/usr/lib/python3.4/os.py”, line 237, in makedirs
mkdir(name, mode)
PermissionError: [Errno 13] Permission denied: ‘/usr/local/lib/python3.4/dist-packages/pyenvisalink-1.5.dist-info’
I am very new at this, so I have no idea how to fix this. Any suggestions? (And apologies for hijacking this thread, but I would love to help out in the development by submitting my error logs, once I get updated)
Okay- I think I need some help here- I see the issue, but am not putting the puzzle together…
@balloob, do you think you could shed some light on how the statically defined entities from configuration.yaml are loaded vs. the ones that i’m loading dynamically in the envisalink platform? Does all that loading occur synchronously in the main thread?
We have a bizarre issue where, when the envisalink platform loads up it’s sensor/binary_sensors- some other statically defined binary_sensors fail to load entirely- it’s like the loader isn’t even attempting to load them. This appears to happen randomly when starting hass. Seems like a critical race issue to me, but I don’t know enough about the loading process to spot it.
Cinntax - only had a chance to install the latest last night and had a quick play - looking great - now getting specific messages in the alpha section. Will do some proper testing tonight and feedback.
Thanks once again.
Fantastic work Cinntax & co, got HA up and running on a Pine64 earlier in the week with my DSC PC1616 very easily. Setup first automation rule last night to turn on the lights in the kitchen when motion detected via the alarm.
I might have a look at the code myself when I get some time as would love to be able to toggle the programmable output (or just send arbitrary keypresses) as I’ve got a relay running through the programmable output.
Cheers
Great- I’m glad it works for you. We’re in the middle of adding support for triggering the alarm from HA (using the panic features of the DSC), and also reporting back on some of the other partition statuses that we’re currently ignoring.
I think perhaps I’ll just open an issue in github for the startup issue- as i’ve been unable to determine the cause, and I’ll need some help. I’m not totally convinced it’s anything that I’m doing.
Hi Cinntax,
Sorry to have gone so quiet but I’ve been doing lots of bits and pieces with my DSC alarm - not least “going live” by finally hooking up the external sounder which has meant my testing has had to be careful and slow going.
So I did extensive testing of the statuses and here are my findings:
The statuses did seem to update briefly but I haven’t been able to get them to update again and I feel like I’ve tried everything! I installed your panic branch on a whole different machine and completed cleared the config and tried everything but they just wouldn’t update.
Then I was scouting around online for some more information and found this https://sites.google.com/site/mppsuite/downloads/dscserver-2 which is a Java DSC envisalink server which interfaces with the envisalink and allows multiple clients to connect to it whilst relaying between the Envisalink - its a middleman. Its been a bit helpful for testing because it has an option to fake the system in alarm which is great for testing automations etc. Anyway in testing with this (i.e. pointing my config to this java server) your new statuses like chime, ac_present etc works fine. The downside to using this is that it does not update the binary sensors in DSC. However when I point the config directly to the Envisalink I don’t get anything for the statuses - its so weird - I don’t see anything in the logs either but the sensors and arming and disarming seem fine. This means your code has to be working but for seem reason not when talking directly to the Envisalink.
For the time being I wonder if you should commit the changes to the main tree – the development branch is hundreds of commits ahead and I tried a clean install on a VM and the envisalink component fails to load in the latest HA because I think its search for 1.0.
Okay thanks Sam- yeah at this point I think I will just start working up a pull-request and get a new version out there- certainly can’t hurt to get some of these other statuses out there- my current changes also clears up some of the log spam as well.
So my current understanding is that, you’ll very briefly see a status, but then it disappears again- right?
One thing I noticed on my system too is- for my motion sensors, it won’t always show as tripped in the UI if I walk past it, but I do see a blip in the history for it. It’s almost like we’re getting the change in status, but it’s “too short” to really be displayed in the web interface.
If you were to look at your sensor/binary sensor histories, do those appear to be consistent?