Thinks we should get MCV working with Sean at Nutech so we can get a Luup Plugin written for AD2USB.
It’s queued. I already talked to Sean and somewhere in the near future I will develop a plugin for this.
Sounds good–it’d be great to be able to have Vera work with my alarm!
If you need a guinea pig let me know I have AD2USB installed and ready to go!
I have an AD2USB connected to a “spare” VERA. If you’d like to log into my system to develop/test the plug in you’re welcome to use it.
Okay, getting back to main point of this thread. 
Status Update:
I have the code at 75% written. All zones and partitions are instantiated. Faults update the zones.
Code Left Todo:
- Finish writing all System Event Handlers (there are almost 200 of them!)
- Implement arming code
- Clean-Up
Looks by the end of the weekend I will have some code available for test. Anyone have a system that they want to test on?
I can send out an AD2USB to anyone who would contribute in the development of the plugin for my AD2USB device.
Currently I am tied up a bit in development of an Android virtual keypad and Ethernet support so I do not currently have time but will do
anything I can do facilitate this happening.
The latest feature I added to the AD2USB is a long range radio emulator. This now allows one to know what user armed/disarmed.
If anyone who would be interested please let me know. It sounds like we have a few people with an AD2USB already and want to test.
Re
Sean M
dfad1469,
Looks like Ademco V20P users like me can’t use VA8201 or 4100SM as per company documentation, so based on the little knowledge I have, looks like the only option is AD2USB.
As per the post above, mathewss is willing to send out AD2USB. Hopefully, you can look into developing something for people like us.
shahhim
[quote=“dfad1469, post:26, topic:168386”]Okay, getting back to main point of this thread.
Status Update:
I have the code at 75% written. All zones and partitions are instantiated. Faults update the zones.
Code Left Todo:
- Finish writing all System Event Handlers (there are almost 200 of them!)
- Implement arming code
- Clean-Up
Looks by the end of the weekend I will have some code available for test. Anyone have a system that they want to test on?[/quote]
I have a question about the 4100SM. In order to know if an internal zone say an interior door was opened / closed while the alarm is armed “STAY” I ended up listening to zone expander messages and RF messages and for the zones directly on the board I use relay emulation to see the event because the alarm itself sends no messages to keypads for a zone that is interior while armed stay. Does the 4100SM show zones open / close even if they are such a zone?
The RF decoding for example lets me use internal motion sensors as occupancy sensors even if they are not programmed into the alarm panel.
Re
Sean M
Status Update:
-Arming Code Complete. Now the Panel Service Variables are updated with the correct Arming State. Also remote arming and disarming work.
-Code cleanup began.
-Ready for Alpha testers
Left Todo:
-Finish writing System Event Handlers
-Test Alarm States
-Remove features that this interface can’t do (Panic, Quick Arm, etc.)
-Sensor Bypass monitoring
-Write page for mios.code.com. Also, upload code to it
I don’t have a 4100SM. My panel (Vista 128BPT) has a RS232 built into it. However, from what I read, it works exactly the same, but I thought I should let you know that up front. That being said, I see the same behavior as you. When the system is in Armed Away (Stay) mode, it bypasses all internal doors and motion sensors. It will not send notifications for those zones to the RS232. I am seeing what happens if I request that they are not bypassed, but I am betting it will just set off the alarm if they are tripped.
I figured this was a bug in Honeywell’s software. However, I am not sure if there is anyone I can notify about it.
Quick update in response to @mathewss. I added a feature that after every Arm or Disarm action, the zones are updated with their current state. This will at least show that the zones are bypassed.
Had to take a couple days of break for work related items. I am working on getting the LCD from the keypads into the VendorStatus of the State of the Partition. Its all kinds of tricky.
I also still need to write all 200 of those handlers.
I have some comments about the programming experience that I have had. I will put them here, but if someone has a better suggestion as to where to post these, I will be more than happy to post them there as well. Once again, I am a professional developer, but I have never used Lua before.
First, luup.io is not very well documented. The two major problems are intercept() and read(). intercept is very poorly documented. It doesn’t speak as to how long an intercept is good for (current scope, current interrupt, etc.), the concept does not seem to take into account the fact that there might be multiple reads in between writes, and the documentation does not give an example of any kind (although it does have a TBD to do so). To be honest, I am having quite a bit of trouble with this methodology.
The read() command is missing time units on the optional timeout parameter. Is it seconds, milliseconds, etc.? Without know this, its impossible to use that parameter.
The json options are not documented anywhere that I can find. Maybe I am just missing them. This brings up another problem I have had: documentation is not well organized. There are scattered wiki pages as well as a wealth of information in the forums, but some of it is outdated and digging through it all is painful. The wiki itself doesn’t have a homepage with organized information. A table of contents would be extremely helpful.
Those are the bad, now the good: people are extremely friendly on the forums and seem to be willing to help out. MCVFlorin really seems to be working hard to improve several aspects of the experience. The new firmware update seem stable.
Thanks to everyone who has helped out.
[quote=“dfad1469, post:33, topic:168386”]First, luup.io is not very well documented. The two major problems are intercept() and read(). intercept is very poorly documented. It doesn’t speak as to how long an intercept is good for (current scope, current interrupt, etc.), the concept does not seem to take into account the fact that there might be multiple reads in between writes, and the documentation does not give an example of any kind (although it does have a TBD to do so). To be honest, I am having quite a bit of trouble with this methodology.
The read() command is missing time units on the optional timeout parameter. Is it seconds, milliseconds, etc.? Without know this, its impossible to use that parameter.[/quote]
Yup, agreed. For the most part, I’ve only had to use [tt]intercept()[/tt] during startup, so I can call [tt]read()[/tt] explicitly. In the rest of the cases, I’ve relied solely on [IO] events coming in via the regular [tt][/tt] block so I can avoid having to wait for blocking IO calls to return.
So far this has worked well, but I can imagine there will be times where I’ll have to set “states” to track where the IO is at in order to handle later dispatch using this model.
The json options are not documented anywhere that I can find. Maybe I am just missing them.No, you're not missing them, everything we're doing in this space has been done by looking at the existing/example [tt].json[/tt] files, that ship with the product, and "combining" them to achieve a desired UI.
It’s a painful process…
This brings up another problem I have had: documentation is not well organized. There are scattered wiki pages as well as a wealth of information in the forums, but some of it is outdated and digging through it all is painful. The wiki itself doesn't have a homepage with organized information. A table of contents would be extremely helpful.Agreed. A lot of this feedback has been given to the MCV Management, both casually in the Forums, and formally via Email and Bugs.
As users, we tend to “tweak” pages where we can once we have the information, but it’s really touching around the edges of the problem. Recently folks like @Henk have been updating the Wiki pages for the more user-centric issues (a series of HowTo pages, a Starting page on the Wiki itself, etc).
For Plugin authors, we’ve traditionally relied upon using the existing Plugin codes as “samples” to garner the real information from. It’s part of why we had the original Development contact (Javier) create code.mios.com for us, so we could readily share code, and use it as a training ground of sorts (code-by-example, if you will)
That said, you can request a wiki.micasaverde.com account, and get access to changing the pages and helping to add structure.
Those are the bad, now the good: people are extremely friendly on the forums and seem to be willing to help out. MCVFlorin really seems to be working hard to improve several aspects of the experience. The new firmware update seem stable.Yeah, generally you'll find people here more than willing to help out, share ideas and code freely, and help iron out "the bumps". Let us know when you have code ready and if you'd like some of us to go over it (etc). It's always a learning curve with this stuff...
It does speak as to how long an intercept is good:
This is also explained in the Wiki:
This is true. I plan to document this when I find some time. Until then, the best thing that I have for a documentation is the file I attached. This lists all the non-deprecated json tags. I must admit that even I don’t know what all these tags do. The json file structure is a mess. It has tags that aren’t used in UI4 but are there for compatibility reasons with UI3. There are also some redundant tags. There was an attempt to clean the json file, but there were some high priority tasks pending so this never happened.
This is the reason I try to make the interface for my plugins in a separate JavaScript file. Not only it’s a lot more flexible, but it is also easier to make more usable interfaces.
There were 2 issues with the JavaScript interfaces:
- They didn’t work when the UI was accessed remotely through cp.mios.com. - SOLVED -
- They require to click the tabs twice. This will be solved as soon as the web-based plugin wizard is done.
Thanks for the replay @mcvflorin. Sorry for my delay in response. Things have been hectic at work in a good way.
Anyway, I disagree with some of the documentation. For example, if you check the return status of the intercept() function, then it is false after the first intercept. Subsequent intercepts, even after reads return false. This leads me to believe that the intercept is good for a certain amount of time.
Also, even when set behind reads, some actions slip through. The problem is that the protocol is designed so that you perform the following actions:
1 intercept
2 write
3 read
The intention of performing the intercept before the write is that the read will be in response to the write so if you set the intercept before the write, then you won’t miss the read as you could in this example
1 write
2 intercept
3 read
In this case, the read could come in when you set the intercept, so it is not recommend that you do this. Now, lets take the example further and add multiple reads. For example, lets say that a write command will result in two lines that you have to read:
1 intercept
2 write
3 read
4 intercept
5 read
This is what the documentation that you pointed out suggests. However, what if the read comes in during the intercept in step 4? Then you miss it and it goes to the handler. In fact, I am seeing this case sporadically. This is very frustrating.
Also, I still don’t know the time unit for the read(n) timeout. What time unit is n? ms? s? us?
Finally, where is the the JavaScript plug in documentation? This is the first I have heard of it.
Thanks again!
The time unit for timeout is seconds. I updated the wiki to specify this.
You can find the documentation here:
http://wiki.micasaverde.com/index.php/JavaScript_API
As for the luup.io.intercept, it’s true that there are limitations to its usability, which means you should try to work around this limitation by reducing the number successive reads.
Thanks for the update to the wiki. Also, thanks for the JavaScript link. I will check it out this weekend.
As to limiting consecutive reads…well, I don’t write the alarm panel protocols…
This race condition is probably what is causing the Caddx security plugin to mess up when people walk around the house during Luup Engine reload. It’d be nice to have a version of luup.io.intercept() that stayed sticky until it was explicitly switched off. I don’t have the option of “reducing the number [of] successive reads” because the Caddx protocol requires me to read the output a byte at a time.
I’ll put a feature request into the bugtracking system.
Hi guys, check out this link:
Click on the upper right link “goto product”, and select “wireless BAT”, this devce connects to the keybus and has emulation for DSC, GE and Honeywell/ADEMCO, sends the data via Zigby, to a wireless gateway they also make… They are working on a bunch of Zigby home automation and energy monitoring/control products.
Anyway, might be a workable interface to several keybus compatible alarm systems to Vera
Mitch