No, not right now from me. I am a bit handicapped until I get back. But I changed names in RP and your app did it's job. Devices are listed correctly.
I just noticed the some devices do not have a DNI shown in the list, but it does have it listed in the device property page. Not sure if that means anything.
Thanks
A new Elk M1 driver and Task Driver have been uploaded to github.
Cheers
Mike
Elk-M1-Driver-beta v0.1.17 (You will have to uninstall the app and reinstall everything with this one. This change though will allow us to remove devices and change drivers after install)
Elk-M1-Driver-Task v0.1.2 (You don't have to update this one since it was only cleaning up code)
Everythings been working great!! Love the auto device population.
Do you happen to know how to add one of the application buttons to a dashboard? Would love to be able to just click on my dashboard and arm/disarm the system
Unfortunately, this isn't very straight forward. So here is what I did.
Add a virtual switch device and name it 'armnight' or 'arm' or 'disarm'. Create one for each command you would like.
Click on rule machine - Create custom commands - Select Actuator - Select Elk M1 - Select Command - Save Command Now (This will actually arm the system for some reason so be prepared to disarm)
Click rule machine - Create new rule - Name Rule - Select capability Switch - Select Elk M1 Disarm or Arm - Click Select Actions for True - Run Custom Commands Select Disarm or Arm - Personally I also switch the virtual switch to off at this point but a better way may be to switch it off when you do the opposite command
You can then add them to a dashboard app and add tile to dashboard.
Good Luck
Mike
I don’t have an Elk panel, but what I did with my security panel integration is to sync with modes. Arm stay is night, Away is away, and disarm is day. This way I can just change mode using the stock mode switcher and my panel follows and vice versa. Just throught I would throw this idea out there.
Thanks for the heads up! I will give this a go.
I just got back home and so far this is a little issue I found.
Tripped a PIR motion sensor.......
2019-03-14 04:26:48.609 pm Zone 013 - Tea Rm PIR is inactive
2019-03-14 04:26:48.600 pm Elk M1 Module: Connection Driver: Motion Inactive
2019-03-14 04:26:48.586 pm Elk M1 Module: Connection Driver: Zone 013 - Tea Rm PIR
2019-03-14 04:26:48.572 pm Elk M1 Module: Connection Driver: ZoneChange: 013 - 3 - Normal: Short
2019-03-14 04:26:48.563 pm Elk M1 Module: Connection Driver: Parsing Incoming message: 0AZC013300CB
Tripped a PIR occupancy sensor....
2019-03-14 04:38:58.441 pm Elk M1 Module: Connection Driver: ZoneChange: 085 - 1 - Normal: Open
2019-03-14 04:38:58.432 pm Elk M1 Module: Connection Driver: Parsing Incoming message: 0AZC085100C4
2019-03-14 04:38:51.285 pm Elk M1 Module: Connection Driver: Parsing Incoming message: 0AZC088100C1
2019-03-14 04:38:50.258 pm Elk M1 Module: Connection Driver: ZoneChange: 085 - Unknown zone status message
A security motion is a "normaly closed" device. An occupancy motion is a "normally open" device.
Both devices are seen and logged with your app. However it seems the logs show that the occupancy data (being reversed) is messing up your apps logic and throws a "Unknown zone status message". Also in the logs, security PIR's also show the labels (Elk M1 Module: Connection Driver: Zone 013 - Tea Rm PIR) whereas the occupancy PIR's show labels as "Connection Driver: ZoneChange: 085" leaving off the rest of the label.
I've been testing away and it looks like the sensors are all working.......except my occupancy sensors. For some reason these types of sensors, which are just fast action omni motion devices, are normally open. Just the opposite of a security motion. Go figure. Also I cannot change the sensor relay so it is normally closed.
So if you have a way to create another device "occupancy motion" and code it so it work the other way around from you motion sensor, then I think that would work.
Maybe even if you added another field to your motions that can select weather it is normally open or normally closed.
EDIT: I did some research and found out why they are designed this way. An occupancy sensor closes when tripped since they are usually wired directly to a lighting circuit so a light will turn on. You can add relay delay up to 15 minutes to keep lights on after tripped.
Ok thanks for letting me know the reason for this. I will work this hopefully into the next release.
Cheers
Mike
So where should it show active vs inactive?
Which one should show active:
Normal Open
Violated Short
The occupancy is normally open so it should show active when closed(violated short).
I set these with a no relay delay which shorts for 2 sec, then opens again. Of course if there is any movement in the room it will quickly violate again as expected.
I posted a new Elk M1 Driver to github. This update is for occupancy sensors. It might take me a bit longer to implement them properly but for now I am going to use this code to see if it fixes the issues. I didn't test this code but it should at least provide more information then before.
if (zoneStatus == '1') {
ifDebug("ZoneChange: " + zoneNumber + " - " + zoneStatus + " - " + NormalOpen);
//This should actually be zoneOpen but in order to show inactive status we are using zoneClosed.
zoneClosed(message)
if (zoneStatus == 'B') {
ifDebug("ZoneChange: " + zoneNumber + " - " + zoneStatus + " - " + ViolatedShort);
//This should actually be zoneClosed but in order to show active status we are using zoneOpen.
zoneOpen(message)
Hi Mike,
I just did a test with the beta driver. Changed my occupancy sensors to Virtual Presence and got the following tripping 2 of my sensors........
2019-03-16 05:14:37.345 pm debugElk M1 Module: Connection Driver: Motion Inactive
app:10432019-03-16 05:14:36.558 pm debugElk M1 Module: Connection Driver: Zone 085 - OFC Occupancy
app:10432019-03-16 05:14:35.796 pm debugElk M1 Module: Connection Driver: ZoneChange: 085 - 1 - Normal: Open
app:10432019-03-16 05:14:35.101 pm debugElk M1 Module: Connection Driver: Parsing Incoming message: 0AZC085100C4
app:10432019-03-16 05:14:33.694 pm debugElk M1 Module: Connection Driver: Ethernet: 16XK07071771603190110063
app:10432019-03-16 05:14:32.934 pm debugElk M1 Module: Connection Driver: Parsing Incoming message: 16XK07071771603190110063
dev:31232019-03-16 05:14:28.348 pm errorgroovy.lang.MissingMethodException: No signature of method: virtualPresence.active() is applicable for argument types: () values: [] Possible solutions: arrived(), asType(java.lang.Class), notify(), wait(), wait(long), with(groovy.lang.Closure) on line 660 (active)
app:10432019-03-16 05:14:28.313 pm debugElk M1 Module: Connection Driver: Motion Active
dev:28512019-03-16 05:14:27.608 pm debugZone 085 - OFC Occupancy
app:10432019-03-16 05:14:27.593 pm debugElk M1 Module: Connection Driver: ZoneChange: 085 - B - Violated: Short
app:10432019-03-16 05:14:26.831 pm debugElk M1 Module: Connection Driver: Parsing Incoming message: 0AZC085B00B3
dev:29342019-03-16 05:14:23.126 pm errorgroovy.lang.MissingMethodException: No signature of method: virtualPresence.inactive() is applicable for argument types: () values: [] Possible solutions: notify(), arrived() on line 695 (inactive)
app:10432019-03-16 05:14:23.097 pm debugElk M1 Module: Connection Driver: Motion Inactive
app:10432019-03-16 05:14:22.364 pm debugElk M1 Module: Connection Driver: Zone 083 - LIV Occupancy
app:10432019-03-16 05:14:21.617 pm debugElk M1 Module: Connection Driver: ZoneChange: 083 - 1 - Normal: Open
app:10432019-03-16 05:14:20.914 pm debugElk M1 Module: Connection Driver: Parsing Incoming message: 0AZC083100C6
dev:29342019-03-16 05:14:15.736 pm errorgroovy.lang.MissingMethodException: No signature of method: virtualPresence.active() is applicable for argument types: () values: [] Possible solutions: arrived(), asType(java.lang.Class), notify(), wait(), wait(long), with(groovy.lang.Closure) on line 660 (active)
app:10432019-03-16 05:14:15.710 pm debugElk M1 Module: Connection Driver: Motion Active
dev:28512019-03-16 05:14:14.978 pm debugZone 083 - LIV Occupancy
app:10432019-03-16 05:14:14.956 pm debugElk M1 Module: Connection Driver: ZoneChange: 083 - B - Violated: Short
app:10432019-03-16 05:14:14.216 pm debugElk M1 Module: Connection Driver: Parsing Incoming message: 0AZC083B00B5
dev:29342019-03-16 05:14:11.106 pm errorgroovy.lang.MissingMethodException: No signature of method: virtualPresence.inactive() is applicable for argument types: () values: [] Possible solutions: notify(), arrived() on line 695 (inactive)
Try them as motion sensors.
I think you got it! Looks like it's working, and even set up in a dashboard, it is correct. Way to go there Mike.
Here is the OFC occupancy as a Virtual Motion Sensor........
2019-03-16 11:51:30.759 pm infoZone 085 - OFC Occupancy is inactive
app:10432019-03-16 11:51:30.741 pm debugElk M1 Module: Connection Driver: Motion Inactive
app:10432019-03-16 11:51:30.031 pm debugElk M1 Module: Connection Driver: Zone 085 - OFC Occupancy
app:10432019-03-16 11:51:29.312 pm debugElk M1 Module: Connection Driver: ZoneChange: 085 - 1 - Normal: Open
app:10432019-03-16 11:51:28.587 pm debugElk M1 Module: Connection Driver: Parsing Incoming message: 0AZC085100C4
dev:31232019-03-16 11:51:23.777 pm infoZone 085 - OFC Occupancy is active
app:10432019-03-16 11:51:23.758 pm debugElk M1 Module: Connection Driver: Motion Active
dev:28512019-03-16 11:51:23.044 pm debugZone 085 - OFC Occupancy
app:10432019-03-16 11:51:23.022 pm debugElk M1 Module: Connection Driver: ZoneChange: 085 - B - Violated: Short
app:10432019-03-16 11:51:22.288 pm debugElk M1 Module: Connection Driver: Parsing Incoming message: 0AZC085B00B3
app:10432019-03-16 11:51:15.259 pm debugElk M1 Module: Connection Driver: Ethernet: 16XK47432371603190110062
app:10432019-03-16 11:51:14.555 pm debugElk M1 Module: Connection Driver: Parsing Incoming message: 16XK47432371603190110062
--- Live Log Started, waiting for events ---
Uh-Oh...problem. Now the security PIR's are randomly violating even though they are not being tripped. There is a long delay between a device tripped and it shows on the dashboard (over 25 sec). Same thing for a device to show reset. I notice the Elk M1 Application logs never stop scrolling, polling through all devices and alarm status. This would account for the delays when a device is tripped.
So, while things do actually happen correctly, the log entries never stop.
I was thinking I needed to clean up the logging. Do you think this is the problem? There is alot of talking go on.
Yes. A lot of logging/talking. It totally effects ALL devices where actions are delayed at least 20-30 seconds.
I uploaded a new Elk M1 Driver! Let me know if this helps with the delay issues at all. I didn't change much but I did edit out a line of code that contained a fairly significant amount of code logging data.
Trying this driver........
2019-03-18 08:45:17.425 am errorjava.lang.IllegalArgumentException: null on line 876 (parse)
dev:28512019-03-18 08:45:16.569 am errorjava.lang.IllegalArgumentException: null on line 876 (parse)
dev:28512019-03-18 08:45:03.702 am errorjava.lang.IllegalArgumentException: null on line 876 (parse)
I looked at past logs and see this this error just started happening last night with the old version as well.
Everything was working fine before I went to bed.
What do you think?
Download the Hubitat app
