That looks about right. My alarm panel is connects over an Ethernet bridge so I don’t use the Vera Serial Port Configuration page, but as long as you’ve set the speed, stop bits, data bits and parity you should be good.
futzle, Any update on Version 80? Looks like it’s still not approved by MCV…
I know as much as you do, sorry. I suspect that approval is totally manual on their end. They don’t inform me of where a version is in the approval pipeline.
Futzle, Updated to Version 80 and it’s working fine. Thanks again for great plugin and support.
I want to thank Futzle and everyone else that contributed to this plugin, it’s really nice! I have just switched over to a Vera 3 from Nexia as I moved into a new home with a Caddx system. I added the NX-584 and it’s communicating! I haven’t been able to get zone scanning to work but I can manually add them, although in UI7 it’s a bit of a pain because it seems I need to do a lot of waiting and refreshing.
I would like some assistance to narrow down the reason that I am unable to arm/disarm from the Vera UI7 Android app. I can control the unit from the web login, and I see the device on the mobile app, but there is no button to arm or disarm. I assume this is just an issue with the Vera UI7 Android app but if anyone has input please advise.
The app developer would need to add support for the plug-in. In this case MicasaVerde the owner of the Vera app would need to add support. Not every plug-in or device is supported by every app.
- Garrett
Thanks for the info Garrett! I switched to AuthomationHD and it works fine there, and after I did some digging I saw some known issues listed in the change log for Vera. Now that I have all of my zones added in I am able to get alerts based on any of the sensors and I can arm/disarm the system.
So everything seemed great after moving to UI7 but it appears I made the mistake of updating the GE Caddx Plugin to the latest version and upon doing so I’ve noticed that two of my scenes (an arm scene and a disarm scene) have been deleted. When I try and add them back in I’m having all kinds of issues. I hit add scene and then step 1 select manual, then select next for step 2 and select the house alarm as the device then when I hit next it says “No action could be set for selected devices. Please, choose other devices.”
In the old UI I was able to go into the advanced tab and add the device and action but I can’t seem to figure out how to do that in UI7. When I go to advanced it is very limited.
On a side note, if I select the alarm device in step one as a trigger I have all kinds of options, what I would think I would see under the device options in Step 2 as well.
Anyone else having this issue? Maybe I need to delete and re-install completely…
Interestingly enough I’ve solved the problem. When I created the scene I went ahead and added a second device in step two. This enabled the options to add actions under advanced and I was able to re-create the two alarm mode scenes I lost. I was then able to go in and delete the second device and the scene still worked. I realize this is a work around, not not sure why I was not able to make it work on the alarm device itself, but it is now working so if anyone else runs into this try adding a second device in step and then you should be able to play with the alarm device as well.
The Advanced scene editor in 1.7.388 has some interesting quirks. That’s one of them. I discovered the same workaround while wanting to add an action to a scene for my Sonos.
Futzle, I just noticed the current version of the app is 81, and I’m running version 80. I didn’t see the changelog on the code.mios site, is there a place I can find one? Everything is working well so I am in no urge to upgrade unless you recommend it.
I did notice on the code page that you were looking for startup logs from a system with more than 1 partition. I have 2 partitions and my Vera is connected to the Caddx via the NX584 serial card. If you still need these logs I would be happy to help.
Revision log: trunk (log) – GE Caddx Networx NX-584 NX-8E Alarm Plugin
I keep the version numbering in apps.mios.com consistent with this so that you can directly compare. In your specific case, revision 81 has no feature you care about, probably.
Edit: spelling
Thanks Futzle!
I spoke a little too soon about how well this was working for me. I may have misconfigured something with my NX584 during setup but I double and triple checked my config and I think it’s right. I am able to arm/disarm and see armed/disarmed status, however I just realized that it appears to always be in DetailedArmMode: EntryDelay. I only realized it when I set a scene based on the EntryDelay.
Here is a clip of log where the alarm was disarmed, and my girl armed it and bypassed zone 3 (the pet sets it off all the time) and you can see that it was entrydelay even when disarmed.
50 11/17/14 9:45:45.804 luup_log:18: Sending message: 0x1D Positive Acknowledge <0x2ed78680>
50 11/17/14 9:45:45.805 luup_log:18: Message: Outgoing: 0x7e 0x01 0x1d 0x1e 0x1f <0x2ed78680>
50 11/17/14 9:45:45.991 luup_log:18: Received good message 0x06, acknowledge requested <0x2ed78680>
50 11/17/14 9:45:45.991 luup_log:18: Message: Incoming message body: 0x00 0x60 0x00 0xc8 0x00 0x62 0x84 0x83 <0x2ed78680>
50 11/17/14 9:45:45.992 luup_log:18: Handling message: 0x06 Partition Status <0x2ed78680>
50 11/17/14 9:45:45.993 luup_log:18: Setting state for partition 1 <0x2ed78680>
06 11/17/14 9:45:45.993 Device_Variable::m_szValue_set device: 19 service: urn:micasaverde-com:serviceId:AlarmPartition2 variable: LastUser was: Millie now: User 98 #hooks: 0 upnp: 0 skip: 0 v:0xc40bf8/NONE duplicate:0 <0x2ed78680>
50 11/17/14 9:45:45.994 luup_log:18: ChimeEnabled: 1 <0x2ed78680>
06 11/17/14 9:45:45.994 Device_Variable::m_szValue_set device: 19 service: urn:micasaverde-com:serviceId:AlarmPartition2 variable: ChimeEnabled was: 1 now: 1 #hooks: 0 upnp: 0 skip: 0 v:0xc404b8/NONE duplicate:1 <0x2ed78680>
50 11/17/14 9:45:45.994 luup_log:18: AlarmMemory: 0 <0x2ed78680>
06 11/17/14 9:45:45.995 Device_Variable::m_szValue_set device: 19 service: urn:micasaverde-com:serviceId:AlarmPartition2 variable: AlarmMemory was: 0 now: 0 #hooks: 0 upnp: 0 skip: 0 v:0xc40678/NONE duplicate:0 <0x2ed78680>
50 11/17/14 9:45:45.995 luup_log:18: Alarm: None <0x2ed78680>
06 11/17/14 9:45:45.995 Device_Variable::m_szValue_set device: 19 service: urn:micasaverde-com:serviceId:AlarmPartition2 variable: Alarm was: None now: None #hooks: 1 upnp: 0 skip: 0 v:0xa9e408/NONE duplicate:1 <0x2ed78680>
50 11/17/14 9:45:45.996 luup_log:18: DetailedArmMode: EntryDelay <0x2ed78680>
06 11/17/14 9:45:45.996 Device_Variable::m_szValue_set device: 19 service: urn:micasaverde-com:serviceId:AlarmPartition2 variable: DetailedArmMode was: EntryDelay now: EntryDelay #hooks: 1 upnp: 0 skip: 0 v:0xc40400/NONE duplicate:1 <0x2ed78680>
50 11/17/14 9:45:45.996 luup_log:18: ArmMode: Armed <0x2ed78680>
06 11/17/14 9:45:45.997 Device_Variable::m_szValue_set device: 19 service: urn:micasaverde-com:serviceId:AlarmPartition2 variable: ArmMode was: Disarmed now: Armed #hooks: 0 upnp: 0 skip: 0 v:0xc40388/NONE duplicate:0 <0x2ed78680
Any ideas? I also notice that when it goes through an entrydelay it always shows user 98, which doesn’t exist. I assumed that was just reflecting that the NX8 did something on it’s own.
User 98 is the user that the system reports when you press the Away or Arm button on the keypad without entering a PIN. I named that user “Keypad” on my own Vera.
Your snippet of log definitely shows that the DetailedArmMode is getting stuck. That shouldn’t happen. But from that snippet I can’t see what broke because it happened before the capture began. If you can catch the log around the instant the alarm goes from Exit Delay to Armed, or from Armed to Entry Delay, or from Entry Delay to Disarmed (but scrub the log to prevent me seeing your PIN), I might have a better chance.
Edit: on further reflection I think I have enough information from you already. I think that the plugin is getting confused over the fact that there are two possible entry delays configurable per partition. I’m at work right now but when I get home I will give you a patch to try out.
Edit: Try this variant of the L_CaddxNX584Security.lua file. It’s less sensitive to the “Entry Delay” bits in the Partition Status message, one of which for you is inexplicably turned on permanently. I hope it doesn’t lead to false negatives for other users…
[quote=“futzle, post:34, topic:182482”]User 98 is the user that the system reports when you press the Away or Arm button on the keypad without entering a PIN. I named that user “Keypad” on my own Vera.
Your snippet of log definitely shows that the DetailedArmMode is getting stuck. That shouldn’t happen. But from that snippet I can’t see what broke because it happened before the capture began. If you can catch the log around the instant the alarm goes from Exit Delay to Armed, or from Armed to Entry Delay, or from Entry Delay to Disarmed (but scrub the log to prevent me seeing your PIN), I might have a better chance.
Edit: on further reflection I think I have enough information from you already. I think that the plugin is getting confused over the fact that there are two possible entry delays configurable per partition. I’m at work right now but when I get home I will give you a patch to try out.
Edit: Try this variant of the L_CaddxNX584Security.lua file. It’s less sensitive to the “Entry Delay” bits in the Partition Status message, one of which for you is inexplicably turned on permanently. I hope it doesn’t lead to false negatives for other users…[/quote]
Thanks Futzle! I really appreciate the help. Here are some of the before logs, but I am still not sure I captured what you are looking for. In all of the logs I have seen, it is always entrydelay no matter what. You are correct in stating there are 2 possible entrydelay timers, and I think mine are both set to a time but I don’t think any zones are set on delay 2.
Also, I do have 2 partitions, one is my shop and it’s pretty much always armed. I did not notice if this was an issue before I added the partition. Another item of note is that I partitioned the system after installing the plugin, but there didn’t seem to be any issues with that and the new partition came up as a new device right away.
I am adding the new file now and will report back. Thanks again!
And BOOM! Just like that, you fixed it. Great job! I really appreciate the assistance. I owe you a couple of beers. Startup log attached. It’s currently reporting correctly for both partitions. Hopefully that will remain true during entry and exit delay modes.
While I am here I want to clue you in on another strange thing with UI7 that you may already know about. I did some testing with my girlfriend last night while you were writing the fix and found that most of your comments about UI7 and the Caddx hold true in relation to devices (zones) being armed or bypassed when bypass is enabled on the NX584. When armed, I am able to bypass zones, and that reflects properly on the Caddx, however I noticed that when the HouseMode changes in UI7 the bypass/armed status of the devices does not sync with the Caddx (at least when the Caddx is disarmed and ready). Example: Caddx disarmed and ready, I switched the UI7 HouseMode to Home, which I have configured under “My Modes” do bypass motion sensors and some doors. The Caddx does not bypass those zones, however when the Caddx is armed and I bypass one in Vera it does switch to bypass. I did not test switching modes while the Caddx was armed. This is not really a huge issue for me, just something that I noticed.
And a question about Caddx configuration: My Caddx seems to be set to only arm when it’s “ready” and an exit has to be detected during exitdelay in order to arm else it switches to stay. How does this affect my remote control with the plugin? If I disarmed my shop right now over the web, and clicked arm again, then I assume there would be a failed exitdelay and it would switch to stay. Then if my girlfriend happened to open the door the alarm would be instant instead of entrydelay. Can I just disable automatic bypass at location 23, segment 1, to resolve this issue?
Thanks for confirming that the change works for you. I’ll include it in version 82 so you won’t need to patch the file manually again.
I’m afraid that I’ve got no suggestions about the remote arming away/stay conundrum. My NX-4 hasn’t been configured that way so it’s always Worked For Me. I guess you could just try it and see. (To be honest, I didn’t know that the Caddx alarm suffered from this “feature”; there’s a great deal of discussion on the DSC alarm forums about a very similar behaviour, which I thought was limited to that system. So I learned something.)
The whole House Modes fiasco in UI7, where you have to specify Arm or Bypass for every sensor without the option to leave its state unchanged, is why I’m now recommending you go back to your NX-584 or NX-8E and disable the Toggle Zone Bypass message in the interface. You lose the ability to bypass a zone from Vera, but you don’t run the risk of a house mode change disabling your entire security system.
[quote=“futzle, post:37, topic:182482”]Thanks for confirming that the change works for you. I’ll include it in version 82 so you won’t need to patch the file manually again.
I’m afraid that I’ve got no suggestions about the remote arming away/stay conundrum. My NX-4 hasn’t been configured that way so it’s always Worked For Me. I guess you could just try it and see. (To be honest, I didn’t know that the Caddx alarm suffered from this “feature”; there’s a great deal of discussion on the DSC alarm forums about a very similar behaviour, which I thought was limited to that system. So I learned something.)
The whole House Modes fiasco in UI7, where you have to specify Arm or Bypass for every sensor without the option to leave its state unchanged, is why I’m now recommending you go back to your NX-584 or NX-8E and disable the Toggle Zone Bypass message in the interface. You lose the ability to bypass a zone from Vera, but you don’t run the risk of a house mode change disabling your entire security system.[/quote]
Thanks for such a quick fix! I have been reading the NX8 manual and if I just disable the auto bypass I think it will kill the remote arming issue. It’s not even that big of a deal if it goes into stay mode as long as it gets disarmed from the app instead of opening the door. I’m really just happy to see a detailedarmmode so I can use the system to trigger scenes.
I don’t mind the toggle zone bypass, as I am always deployed and I prefer to have the capability to make changes remotely. From my little bit of testing yesterday it appears that a house mode change won’t disable anything, as I can only get the Caddx to bypass a sensor when I toggle it individually in Vera. Since I am always away I am would even consider entering the program mode from your plugin if that is possible. Getting my girlfriend to make changes at the keypad is not my preference.
Futzle, once again I spoke too soon! I should stop doing that. Everything was fine until the first exitdelay. I set a scene to bypass zone 3 upon exit delay and it appears the scene ran. It also switched to away mode but it seems at that point the Vera crashed. It appeared that the exit door never closed which would have caused an exit error I suppose but indeed the door was closed. I suppose it was a bad idea to bypass a zone while in exitdelay. Now I have no connection and the log has this repeated message:
50 11/18/14 13:12:25.551 luup_log:18: Global handlers not set up yet <0x2f764680>
50 11/18/14 13:12:25.551 luup_log:18: Global handlers not set up yet <0x2f764680>
50 11/18/14 13:12:25.552 luup_log:18: Global handlers not set up yet <0x2f764680>02 11/18/14 13:18:09.823 e[33;1mMMSStorage::GetDataToSend sending everything--BROADCASTe[0m <0x303aa680>
01 11/18/14 13:18:09.824 e[31;1mXXX-MMSStorage::SendData 0xc90740 WOKE 3/0 set:1e[0m <0x2f5aa680>
01 11/18/14 13:18:09.824 e[31;1mXXX-MMSStorage::SendData 0xc90740 donee[0m <0x2f5aa680>
01 11/18/14 13:18:09.825 e[31;1mXXX-MMSStorage::SendData 0xc90740 send 10000e[0m <0x2f5aa680>
01 11/18/14 13:18:09.825 e[31;1mMMSStorage::SendData --BROADCASTe[0m <0x2f5aa680>
01 11/18/14 13:18:09.835 e[31;1mXXX-MMSStorage::SendData GOING TO SLEEPe[0m <0x2f5aa680>
02 11/18/14 13:18:09.829 e[33;1mMMSStorage::GetDataToSend before locke[0m <0x303aa680>
02 11/18/14 13:18:09.839 e[33;1mMMSStorage::GetDataToSend got locke[0m <0x303aa680>
02 11/18/14 13:18:09.840 e[33;1mMMSStorage::GetDataToSend send:10000 sendsize:10000 bytessent:0 buffer:16372e[0m <0x303aa680>50 11/18/14 13:24:38.106 luup_log:18: Ignoring byte 43 <0x2c358680>
50 11/18/14 13:24:38.116 luup_log:18: Ignoring byte 42 <0x2c358680>
50 11/18/14 13:24:38.126 luup_log:18: Ignoring byte 56 <0x2c358680>
I am currently rebooting equipment to see if it will come up, and then I will perhaps try to restore the original file.
Status Update: Sorry for the alarm. That was quite odd, but a couple of Vera reboots and a refresh of the serial port configuration seems to have resolved the issue. I may have had an exiterror, so my girl is going to test the door sensor several times. I’ve modified the questionable scene to wait 5 minutes to bypass the zone, we’ll see how that goes.
I did log most of that activity in putty, so if any of it interests you I can upload it.
Reason for edit:Status update
Futzle, your patch is still working very well, however I rebooted today and it seemed to end up in a strange state again. I fixed it by once again changing my baud rate, wait a minute, then change it back.
50 11/22/14 14:47:59.572 luup_log:18: Ignoring byte 28 <0x2bc5a680>
50 11/22/14 14:47:59.583 luup_log:18: Ignoring byte 40 <0x2bc5a680>
50 11/22/14 14:47:59.593 luup_log:18: Ignoring byte 81 <0x2bc5a680>
50 11/22/14 14:47:59.603 luup_log:18: Ignoring byte 18 <0x2bc5a680>
50 11/22/14 14:47:59.613 luup_log:18: Ignoring byte ff <0x2bc5a680>
08 11/22/14 14:48:00.620 JobHandler_LuaUPnP::HandleActionRequest device: 0 service: urn:micasaverde-com:serviceId:HomeAutomationGateway1 action: e[36;1mModifyUserDatae[0m <0x2ea9b680>
08 11/22/14 14:48:00.620 JobHandler_LuaUPnP::HandleActionRequest argument inUserData={"devices":{"devices_83":{"states":{"states_5":{"value":"38400"}}}},"scenes":{},"sections":{},"rooms":{},"InstalledPlugins":[],"PluginSettings":[],"users":{}} <0x2ea9b680>
08 11/22/14 14:48:00.621 JobHandler_LuaUPnP::HandleActionRequest argument DataFormat=json <0x2ea9b680>
06 11/22/14 14:48:00.622 Device_Variable::m_szValue_set device: 83 service: urn:micasaverde-com:serviceId:HaDevice1 variable: e[35;1mConfigurede[0m was: 0 now: 0 #hooks: 0 upnp: 0 skip: 0 v:0x7f6610/NONE duplicate:1 <0x2ea9b680>
06 11/22/14 14:48:00.622 Device_Variable::m_szValue_set device: 83 service: urn:micasaverde-com:serviceId:HaDevice1 variable: e[35;1mLastUpdatee[0m was: 0 now: 0 #hooks: 0 upnp: 0 skip: 0 v:(nil)/NONE duplicate:1 <0x2ea9b680>
01 11/22/14 14:48:00.845 e[31;1mUserData::WriteUserData saved--before move File Size: 39629 save size 39629e[0m __LEAK__ this:229376 start:290816 to 0xec3000 <0x2ba5a680>
02 11/22/14 14:48:00.845 e[33;1mUserData::TempLogFileSystemFailure starte[0m <0x2ba5a680>
02 11/22/14 14:48:00.874 e[33;1mUserData::TempLogFileSystemFailure 5206
-rw-r--r-- 1 root root 0 Sep 24 19:15 /etc/cmh/320.reset
-rw-r--r-- 1 root root 33 Nov 16 11:54 /etc/cmh/HW_Key