Ok Mike, NP.
BTW, I am in China! 12:18 am Wed now.
Elk M1 Driver v0.1.21 posted to github. This should fix the output reporting state as well as the alarm reporting states.
Cheers
Mike
You fixed that nicely. But I see another problem with the output parsing as it relates to HE UI.
Outputs are merely just a switch. Your M1 driver now takes care of status of on and off fine. The problem is that HE UI does not know what an output is, therefor the logs list it as Output change update (meaning on) and then it lists Output change update (off). It lists the changes ok, but HE does not see it as a switch, so it is not usable for much. I tried to make a Rule in RM using the output as a trigger, and created a virtual switch to turn on as an action of this rule. But RM cannot detect the ouput operation since there is no definition of an "output" in RM.
Somehow your M1 driver has to parse the output state to the HE UI calling it a switch device so it can see this "switch" go on and off. THEN it can be used in RM rules as a trigger.
BTW, HE's HSM app also has no "output" as a selection.
Make sense? Looks like you are almost there with this project.
Posted a new Elk M1 Driver (see below) to github. I am having trouble with ouputs still.
0.1.22
- Fixed code to show operating state and thermostat setpoint on dashboard tile
- Reorder some code to see if it helps with some delay issues
- Consolidated code for zone open and zone closed to see if it helps with some delay issues (need to check if this has any other impact elsewhere)
Cheers
Mike
OK Mike. I will fire it up and see what happens.
About the outputs, there is the main issue of them not recognized as switches in HE. They do work if I go into the device page and manually turn them on/off. Elk rules also works fine to activate them. But again, RM can see them (as switches), but cannot control them (on/off).
I'll look at your csv file and I have more log data that I can use to add to the csv.
Thanks, Jack
PS- I tested the heck out of the Elk arm/disarm functions in HE today. Ran every test possible and all is working fine.
Jack did you get a chance to test your lighting controls with v0.1.22. In my limited testing my light goes on about 1/2 sec with this driver.
Also, I sent you an email about a separate test driver. In limited testing my light goes on about 1/4 sec with this driver.
I don't use this functionality at this point but just wanted to get an idea of it. I have a hard wired motion sensor back to the Elk M1 panel. The light is a zwave (not a plus) dimmer (leviton) attached to HE controlled by Rule Machine and the motion sensor being tripped.
Let me know if you have any questions or feedback.
I see you're using an ESP8266 for connectivity from the Hubitat to the Elk. Has it been tested with the official Elk ethernet gateway? I'm assuming it will work as the non-encrypted port (2101 I think) seems to be just a simple IP->serial gateway.
Also, if you guys are having trouble with anything, there is a plugin for Vera and you can pull the code down from apps dot mios dot com (sorry, I can't post links yet). It's written in LUA, but at least you'll be able to see how they did certain things. This plugin has been very stable for me for probably 10 years.
Thanks I will take a look at that. Here is a quick update of features and shortcomings thus far:
Direct connect integration via Elk M1XEP (so no ESP8266, I don't have one of these)
Auto zone creation via import tool
Contact and motion uses HE virtual drivers
Thermostat integration custom driver
Output integration custom driver (fixed Rule Machine issue just today)
Task integration custom driver
Currently only tested with 1 Thermostat
Currently only works with Area 1
The delays you may have read about with motion lighting are still being diagnosed. I personally am not experiencing the same issue but then again I don't really use this functionality. In my limited testing, I was achieving less than .5 second delay for light to come on.
It pretty much does everything I need at this point and for me it does it well. The delay issue may be related to this and/or a separate plugin. I will continue to develop further based on user feedback or if my needs change of course.
Cheers
Mike
New drivers uploaded to github!
Elk M1 Driver v0.1.23
- Outputs are now functional with Rule Machine
- Change switch case to else if statements (this is to try and address some delay issues with motion lighting)
Elk M1 Driver Outputs v0.1.2
- Cleaned up code
Cheers
Mike
Unfortunately I discovered an error in the script. I will try and fix it and post an update.
That's good news. I thought something went wacky with your newest driver.
Elk M1 Driver posted to github
0.1.24
- Rerouted some code for efficiency
- Turned off some of the extra debugging
I haven't been able to repeat the errors I thought I saw last night but cleaned up somethings. Give it a try and let me know.
Cheers
Mike
@ekimmagrann, I just installed this. My Zone 001 is a contact sensor on my front door, but it got brought in as a motion sensor. I changed it, but now it's not getting events from the Elk on that zone.
Why would it have come in as a motion in the first place?
After I imported, I did a device mapping for zone 1 and called it just "Front Entry" instead of the "001 - Front Entry". Both devices showed up and I deleted the one I created. Could that be the problem?
What happens if I reimport everything without deleting the devices first? Would this potentially fix it?
And how are you determining if something is a motion or a contact sensor?
Edit: I deleted the device created by the import and then manually created it with the device mapping function. It works now. However, I'm still curious as to why it came in that way. I have some water sensors and smoke sensors hooked into the elk that came in as motion sensors. Am I going to have to delete and re-add those also?
Edit 2: My garage door sensors are wireless Caddx tilt sensors. Works fine with the Elk, but the HE sees the contact as "open" when the door is closed, and "closed" when the door is open. I don't see a way to invert this in the device on the Elk. Also, the HE stopped updating the state of the 'contact' attribute now, however, it does update the "last activity" timestamp when I open or close the door. All of my other door sensors are fine. I just did a test and watched the logs, the HE is seeing at least some of it. You can see where I opened the mud room door and popped my head out to press the button. It registered the garage door opening. Then I closed the garage door, and shut the mud room door. It never registered that the garage door closed.
Ok, here might be the problem with the garage doors not updating state at all in the HE. Still doesn't explain the inverted contact attribute though:
Notice the error line. I do NOT have a device with the same network ID. I deleted the original that came in from the import because it came in as a motion sensor, and then I changed it to a Virtual Contact Sensor when I created the new one.
I'm assuming both garage doors are like this. However, I did the same thing with my front door and had no problems with it. But that's also a wired sensor.
A reboot of the HE fixed that error. But things are still not updating on the HE. I get some logs that door was opened and closed, but they don't show up in the event list for the device at all. There's also an "event is unknown error."
Sorry for the long delay! I should mention that I am by no means a programmer but I will do my best to answer some of the questions.
Importing again will not create duplicates it will skip them if they already exist. It will only import new devices or devices that were deleted from hubitat but still eist in ELK.
Import function needs to find the specified device type here is the logic it is using. If the zone has the word 'door' or 'window' then it sees it as a contact sensor, if it has the word 'motion' then of course motion sensor and anything else is defined as an alert.
Contacts will then use the Virtual Contact Sensor
Motions will use the Virtual Motion Sensor
Alerts get treated as Motion and therefore use the Virtual Motion Sensor
Additionally:
Thermostats should use the Elk M1 Driver Thermostat
Outputs should use the Elk M1 Driver Outputs
Tasks should use the Elk M1 Driver Tasks
I see your name for zone 1 is 'Front Entry' therefore it gets picked up as an alert (motion). I realize using a text match can be unreliable but couldn't think of an easier more efficient way.
I thought about using the elk definitions (01 = Burglar Entry) but for some reason this became complicated.
I have water sensors also and I think mine are messed up. I am not sure how to handle these other types of sensors but once we get you a bit straight then we can see how best to proceed.
Let me know if this answers a a few of your questions and/or if you have any suggestions. Once I got things setup and working for me, I haven't really messed with it much. Once you have it installed properly than we can run some tests and see if events and logging are an issue for you compared to what I see.
Cheers
Mike
There's a plugin for the Vera. It's written in LUA, but everything with that driver gets imported properly. It might be interesting to see how they do it. I have the code.
Frankly, I don't really care, I can presumably manually change the drivers if I need to. The big problem is my garage door sensors only updating in HE the first time, and then never again until I delete and recreate them.
I found the problem with wireless sensors. @ekimmagrann, I sent you the changes. Wireless sensors send a status of "2" when closed (Normal EOL), while wired send "3" (Normal Short). I uncommented some of your code, and added a line to support status 2 as Closed.
It wasn't just my garage door sensors, it was all of my wireless sensors. They correctly parsed the open command, and then would get no further updates because subsequent open status changes weren't a change to the HE, and the HE never got the close status change.
@signal15 - nice to see a familiar face from the CT forums!
@ekimmagrann - awesome work! I am getting my HE today. I've had M1G's in my last two houses, but moved to a new state and bought a new house last year - this confirms I'll be ordering the M1G again soon to use here... Previous house had everything run by the M1 (UPB lights, tstats, garage, sprinklers, etc) - this house has RadioRa2, Ecobee, etc - so I'm hoping the HE will help tie thing together better.
It'll be at least a few weeks before I jump in - just wanted to say that I'm excited to see the progress - and I'd be happy to help any way I can once I get things working.
There seems to be quite a few peeps from CT and the Vera forums here.
1 Like
Best of luck with the new house! The Elk integration is working well for me. I know there is alot more that can be done and there may still be some issues to work out.
Cheers
Mike
1 Like
