openLuup Implementation

CudaNet · January 25, 2016, 6:45pm

Well I was successful in setting up my first panel yesterday for a 24 zone system (with detailed documentation to help others). Everything checked out on the bench and communicated with Envisalink perfectly. Since I’m “attempting” to use Vera for just it’s radio, my purpose was to install this plugin on openLuup (developed by Akbooer). I wasn’t completely successful, however the device appears damn close to acquiring it’s information so I can only think that I’m overlooking something simple that’s required within the environment (e.g module etc.).

Here’s a breakdown of the equipment:

[ul][li]Vista20p[/li]
[li]6160[/li]
[li]Two 4129’s[/li]
[li]Envisalink EVL-4; FW.01.00.77A[/li]
[li]v10.23 Firmware[/li][/ul]

Steps leading up to the issue:

[ul][li]Load plugin - success.[/li]
[li]Update the installer code (differs from default) - success and reloaded.[/li]
[li]Update the EVL password even though it’s default; success and reloaded.[/li]
[li]Performed auto-detect for Envisalink - success. Firmware and MAC acquired.[/li][/ul]

This unfortunately is where I hit a wall (see debug log below). The plugin is indicating there are no zones defined. At this point I needed to verify that an issue wasn’t present so I proceeded to install this plugin on my Vera3 (latest UI7 firmware). I had no issues whatsoever. I followed the exact same steps and it gen’d all the child devices as well as the panel and their respective status (in this case faults on all zones except 1 - fire which has a resistor).

I verified I have Lua bit (BitOP I believe) installed on my openLuup server (OS is latest OpenWRT version) but I don’t see you requiring anything further. I’m interested in the payload back from the EVL (2016-01-25 07:55:54.543 luup_log:74: (EVL3VistaAlarmPanel::configurePanelDevices): processing zone data [NIL].) so I can confirm that the response was indeed nil. Any help or direction is greatly appreciated as I’m sure this is really close to working.

Edit: Plugin is latest version; EVL3Vista_4.00.8_EVL.zip .

2016-01-25 07:55:50.908   luup.call_action:0: 74.urn:micasaverde-com:serviceId:EVL3VistaAlarmPanel1.DetectModule 
2016-01-25 07:55:50.909   luup_log:74: (EVL3VistaAlarmPanel::detectModule): Attempting to AutoDetect panel interface.
2016-01-25 07:55:50.909   luup.task:74: status=1 EVL3VistaAlarmPanel : Attempting to AutoDetect panel interface.
2016-01-25 07:55:50.910   luup.variable_set:74: 74.urn:micasaverde-com:serviceId:EVL3VistaAlarmPanel1.EVL_MAC_Filter was: EMPTY now: 00:1c: #hooks:0
2016-01-25 07:55:51.113   luup_log:74: (EVL3VistaAlarmPanel::findEnvisalink): Autodiscovery found Vera Network [10.0.4.0]
2016-01-25 07:55:51.123   luup_log:74: (EVL3VistaAlarmPanel::findEnvisalink): Loading ARP table
2016-01-25 07:55:51.124   luup_log:74: (EVL3VistaAlarmPanel::findEnvisalink): sending command [ping -c1 -W1 10.0.4.1&]
(Removed by Cuda)
2016-01-25 07:55:52.350   luup_log:74: (EVL3VistaAlarmPanel::findEnvisalink): sending command [ping -c1 -W1 10.0.4.254&]
2016-01-25 07:55:54.356   luup_log:74: (EVL3VistaAlarmPanel::findEnvisalink): ARP table loaded
2016-01-25 07:55:54.357   luup_log:74: (EVL3VistaAlarmPanel::findEnvisalink): Using MAC_FILTER [00:1c:]
2016-01-25 07:55:54.370   luup_log:74: (EVL3VistaAlarmPanel::findEnvisalink): Autodiscovery found Envisalink [10.0.4.124]
2016-01-25 07:55:54.371   luup_log:74: (EVL3VistaAlarmPanel::detectModule): Autodiscovery found Envisalink IP Address - 10.0.4.124
2016-01-25 07:55:54.372   luup.variable_set:74: 74.urn:micasaverde-com:serviceId:EVL3VistaAlarmPanel1.AutoIP was: EMPTY now: 10.0.4.124 #hooks:0
2016-01-25 07:55:54.373   luup_log:74: (EVL3VistaAlarmPanel::resolveAddress): resolving Panel IP Address.
2016-01-25 07:55:54.374   luup_log:74: (EVL3VistaAlarmPanel::resolveAddress): Address resolved: [10.0.4.124:4025].
2016-01-25 07:55:54.374   luup_log:74: (EVL3VistaAlarmPanel::initializeIO): Initializing panel IO connection.
2016-01-25 07:55:54.375   luup_log:74: (EVL3VistaAlarmPanel::verify_EVL):Requesting EVL webpage.
2016-01-25 07:55:54.509   luup.variable_set:74: 74.urn:micasaverde-com:serviceId:EVL3VistaAlarmPanel1.EVL_MAC_Filter was: 00:1c: now: 00:1c:|00:1C: #hooks:0
2016-01-25 07:55:54.511   luup.variable_set:74: 74.urn:micasaverde-com:serviceId:EVL3VistaAlarmPanel1.EVL3Firmware was: EMPTY now: 01.00.77A #hooks:0
2016-01-25 07:55:54.512   luup_log:74: (EVL3VistaAlarmPanel::initializeIO): Verified EVL3 device - firmware version= 01.00.77A.
2016-01-25 07:55:54.513   luup_log:74: (EVL3VistaAlarmPanel::initializeIO): Opening Network connection to EVL3 at 10.0.4.124:4025 Device# 74
2016-01-25 07:55:54.514   luup.io.open:: connecting to 10.0.4.124:4025
2016-01-25 07:55:54.515   openLuup.io:: connect OK
2016-01-25 07:55:54.516   luup_log:74: (EVL3VistaAlarmPanel::initializeIO): InitializeIO successful.
2016-01-25 07:55:54.517   luup_log:74: (EVL3VistaAlarmPanel::detectModule): Success: Detected and connected to EVL3 interface.
2016-01-25 07:55:54.520   openLuup.server:: request completed (38 bytes, 1 chunks, 3613 ms) tcp{client}: 0xaddf58
2016-01-25 07:55:54.528   openLuup.server:: request completed (2469 bytes, 1 chunks, 24799 ms) tcp{client}: 0xad6878
2016-01-25 07:55:54.529   luup.io.incoming:: bytes received: 6, status: OK
2016-01-25 07:55:54.530   luup_log:74: (EVL3VistaAlarmPanel::processLogin) EVL3 Interface requesting Login.
2016-01-25 07:55:54.531   luup.variable_set:74: 74.urn:micasaverde-com:serviceId:EVL3VistaAlarmPanel1.Plugin_Status was: RELOAD required now: Start Login #hooks:0
2016-01-25 07:55:54.532   luup.variable_set:74: 74.urn:micasaverde-com:serviceId:EVL3VistaAlarmPanel1.InterfacePassword was: EMPTY now: user #hooks:0
2016-01-25 07:55:54.534   luup.io.write:: bytes sent: 5, status: OK
2016-01-25 07:55:54.535   luup.io.incoming:: bytes received: 2, status: OK
2016-01-25 07:55:54.536   luup.variable_set:74: 74.urn:micasaverde-com:serviceId:EVL3VistaAlarmPanel1.Plugin_Status was: Start Login now: Logged in... #hooks:0
2016-01-25 07:55:54.537   luup.io.write:: bytes sent: 7, status: OK
2016-01-25 07:55:54.538   luup.task:74: status=4 EVL3VistaAlarmPanel : logged into EVL3.
2016-01-25 07:55:54.539   luup_log:74: (EVL3VistaAlarmPanel::processLogin) EVL3 Login completed.
2016-01-25 07:55:54.540   luup.io.write:: bytes sent: 9, status: OK
2016-01-25 07:55:54.541   luup_log:74: (EVL3VistaAlarmPanel::processLogin) Configuration in progress.
2016-01-25 07:55:54.541   luup_log:74: (EVL3VistaAlarmPanel::configurePanelDevices): Attempting to configure panel device.
2016-01-25 07:55:54.542   luup.variable_set:74: 74.urn:micasaverde-com:serviceId:EVL3VistaAlarmPanel1.Plugin_Status was: Logged in... now: Configuring... #hooks:0
2016-01-25 07:55:54.543   luup_log:74: (EVL3VistaAlarmPanel::configurePanelDevices): processing zone data [NIL].
2016-01-25 07:55:54.544   luup_log:74: (EVL3VistaAlarmPanel::configurePanelDevices): Configuration Failed: No zones defined.
2016-01-25 07:55:54.544   luup.task:74: status=2 EVL3VistaAlarmPanel : Configuration Failed: No zones defined.
2016-01-25 07:55:54.545   luup.variable_set:74: 74.urn:micasaverde-com:serviceId:EVL3VistaAlarmPanel1.Plugin_Status was: Configuring... now: No ZONES defined... #hooks:0
2016-01-25 07:55:54.547   luup.io.incoming:: bytes received: 7, status: OK
2016-01-25 07:55:54.561   openLuup.server:: /data_request?id=user_data&output_format=json&DataVersion=730109768&_=1453730072221 tcp{client}: 0xad6878
2016-01-25 07:55:55.080   openLuup.server:: request completed (255312 bytes, 16 chunks, 518 ms) tcp{client}: 0xad6878
2016-01-25 07:55:55.491   luup.io.incoming:: bytes received: 37, status: OK
2016-01-25 07:55:55.495   luup.io.incoming:: bytes received: 51, status: OK
2016-01-25 07:55:56.000   luup.task:74: status=2 EVL3VistaAlarmPanel : Success: Detected and connected to EVL3 interface.
2016-01-25 07:55:57.117   openLuup.server:: /data_request?id=lu_status2&output_format=json&DataVersion=730110757&Timeout=60&MinimumDelay=1500&_=1453730072222 tcp{client}: 0xad6878
2016-01-25 07:55:57.514   luup.io.incoming:: bytes received: 51, status: OK
2016-01-25 07:55:57.515   luup.variable_set:74: 74.urn:micasaverde-com:serviceId:EVL3VistaAlarmPanel1.PanelTime was: EMPTY now: SAT 01:58PM 01/01/12 #hooks:0
2016-01-25 07:55:57.517   luup.io.incoming:: bytes received: 37, status: OK
2016-01-25 07:55:57.518   luup.io.incoming:: bytes received: 51, status: OK
2016-01-25 07:55:59.030   openLuup.server:: request completed (2688 bytes, 1 chunks, 1913 ms) tcp{client}: 0xad6878
2016-01-25 07:55:59.061   openLuup.server:: /data_request?id=user_data&output_format=json&DataVersion=730109772&_=1453730072223 tcp{client}: 0xad6878
2016-01-25 07:55:59.576   openLuup.server:: request completed (255470 bytes, 16 chunks, 515 ms) tcp{client}: 0xad6878
2016-01-25 07:56:00.082   luup_log:7: synchronisation completed, system monitor started
2016-01-25 07:56:01.558   luup.io.incoming:: bytes received: 37, status: OK
2016-01-25 07:56:01.561   luup.io.incoming:: bytes received: 51, status: OK
2016-01-25 07:56:01.614   openLuup.server:: /data_request?id=lu_status2&output_format=json&DataVersion=730110765&Timeout=60&MinimumDelay=1500&_=1453730072224 tcp{client}: 0xad6878
2016-01-25 07:56:05.602   luup.io.incoming:: bytes received: 37, status: OK
2016-01-25 07:56:05.604   luup.io.incoming:: bytes received: 51, status: OK
2016-01-25 07:56:09.647   luup.io.incoming:: bytes received: 37, status: OK
2016-01-25 07:56:09.649   luup.io.incoming:: bytes received: 51, status: OK
2016-01-25 07:56:13.187   luup.io.incoming:: bytes received: 37, status: OK
2016-01-25 07:56:13.188   luup.io.incoming:: bytes received: 51, status: OK
2016-01-25 07:56:17.232   luup.io.incoming:: bytes received: 37, status: OK
2016-01-25 07:56:17.233   luup.io.incoming:: bytes received: 51, status: OK
2016-01-25 07:56:21.242   luup.task:74: status=4 EVL3VistaAlarmPanel : Clearing...

akbooer · January 25, 2016, 10:57pm

Which of these is the plugin you’re trying?

https://apps.mios.com/search.php?key=envisalink

…or here…

http://forum.micasaverde.com/index.php/topic,35815.0.html

CudaNet · January 25, 2016, 11:01pm

It would be this one,
http://forum.micasaverde.com/index.php/topic,35815.0.html

[quote=“akbooer, post:2, topic:190772”]Which of these is the plugin you’re trying?

https://apps.mios.com/search.php?key=envisalink

…or here…

http://forum.micasaverde.com/index.php/topic,35815.0.html[/quote]

akbooer · January 25, 2016, 11:13pm

I see there is a debug mode - does that give us more info?

Also, a comparison with the Vera log would show us the point of departure, although I think you have that narrowed down pretty well.

CudaNet · January 25, 2016, 11:23pm

Yes, debug mode was enabled (within openLuup) and I can easily generate a Vera log tonight for comparison. Thanks AK for jumping in here - much appreciated… I’m really hoping this is something simple that I’m overlooking. I’ll also hit the Envisalink directly so I can see what’s being returned…

[quote=“akbooer, post:4, topic:190772”]I see there is a debug mode - does that give us more info?

Also, a comparison with the Vera log would show us the point of departure, although I think you have that narrowed down pretty well.[/quote]

CudaNet · January 26, 2016, 2:27am

Here’s an update, I connected (PuTTY) and this is what I see from the Envisalink module:

Login:
user
OK
FE810300000000000000000000000000$
%00,01,0008,09,00,FAULT 09 OFFICE WINDOW 1        $
%01,FE830300000000000000000000000000$
%00,01,0008,10,00,FAULT 10 OFFICE WINDOW 2        $
%01,FE070300000000000000000000000000$
%00,01,0008,11,00,FAULT 11 BAR    WINDOW          $
%01,FE0F0200000000000000000000000000$
%00,01,0008,12,00,FAULT 12 MASTER WINDOW 1        $
%01,FE1F0000000000000000000000000000$
%00,01,0008,13,00,FAULT 13 MASTER WINDOW 2        $
%01,FE3F0000000000000000000000000000$
%00,01,0008,14,00,FAULT 14 MASTER WINDOW 3        $
%01,FE7F0000000000000000000000000000$
%00,01,0008,15,00,FAULT 15 MASTER WINDOW 4        $
%01,FCFF0000000000000000000000000000$
%00,01,0008,16,00,FAULT 16 GUEST  WINDOW          $
%01,F8FF0100000000000000000000000000$
%00,01,0008,17,00,FAULT 17 GUEST  BATHROOM WINDOW $
%01,E0FF0300000000000000000000000000$
%00,01,0008,18,00,FAULT 18        RECREATION ROOM $
%00,01,4C08,08,00,SYSTEM LO BAT                   $
%00,01,2208,01,00,****DISARMED****FIRE TROUBLE  01$
%01,82FF0300000000000000000000000000$
%00,01,0008,02,00,FAULT 02 FRONT  ENTRY DOOR      $
%01,06FF0300000000000000000000000000$
%00,01,0008,03,00,FAULT 03 PATIO  ENTRY DOOR      $
%01,0EFC0300000000000000000000000000$
%00,01,0008,04,00,FAULT 04 GARAGE ENTRY DOOR      $
%01,1EFC0300000000000000000000000000$
%00,01,0008,05,00,FAULT 05 DEN    WINDOW 1        $
%01,3EF80300000000000000000000000000$
%00,01,0008,06,00,FAULT 06 DEN    WINDOW 2        $
%01,7EF00300000000000000000000000000$
%00,01,0008,07,00,FAULT 07 DEN    WINDOW 3        $
%01,FEE00300000000000000000000000000$
%00,01,0008,08,00,FAULT 08 DEN    WINDOW 4        $
%01,FE810300000000000000000000000000$
%00,01,0008,09,00,FAULT 09 OFFICE WINDOW 1        $
%01,FE830300000000000000000000000000$
%00,01,0008,10,00,FAULT 10 OFFICE WINDOW 2        $
%01,FE070300000000000000000000000000$
%00,01,0008,11,00,FAULT 11 BAR    WINDOW          $
%01,FE0F0200000000000000000000000000$
%00,01,0008,12,00,FAULT 12 MASTER WINDOW 1        $
%01,FE1F0000000000000000000000000000$
%00,01,0008,13,00,FAULT 13 MASTER WINDOW 2        $
%01,FE3F0000000000000000000000000000$
%00,01,0008,14,00,FAULT 14 MASTER WINDOW 3        $
%01,FE7F0000000000000000000000000000$
%00,01,0008,15,00,FAULT 15 MASTER WINDOW 4        $

I’ve confirmed the session is closed and I’ll see if I can gather some Vera3 logs in contrast to the openLuup logs…

cybrmage · January 26, 2016, 3:36am

I tried openluup out over the weekend…

The EVL3Vista plugin will NOT fully work when running under openluup…

The openluup implementation has a few major incompatibilities in the IO model as compared to the Vera implementation.

It does not honor or process the tag in the device xml file.
The IO routines appear to be designed for CRLF processing on incoming data, but does LF processing on outgoing data.
When luup.io.intercept is called, luup.io.read does not release the intercept, so normal processing never resumes.
When processing data after a call to luup.io.intercept, the IO routines stop processing incoming data.

Due to these incompatibilities, the “read panel” functions of the plugin will NOT operate.

If you manually configure the zones, the plugin should operate.

CudaNet · January 26, 2016, 3:47am

I truly appreciate the update Cybrmage (and the detail you provided). Looks like there may be some options on the table, for now I’ll defer to Akbooer on how or if this will be addressed.

[quote=“cybrmage, post:7, topic:190772”]I tried openluup out over the weekend…

The EVL3Vista plugin will NOT fully work when running under openluup…

The openluup implementation has a few major incompatibilities in the IO model as compared to the Vera implementation.

It does not honor or process the tag in the device xml file.
The IO routines appear to be designed for CRLF processing on incoming data, but does LF processing on outgoing data.
When luup.io.intercept is called, luup.io.read does not release the intercept, so normal processing never resumes.
When processing data after a call to luup.io.intercept, the IO routines stop processing incoming data.

Due to these incompatibilities, the “read panel” functions of the plugin will NOT operate.

If you manually configure the zones, the plugin should operate.[/quote]

akbooer · January 26, 2016, 10:27am

Well, that’s just shoddy workmanship! Although, in truth, it’s exacerbated by a lack of any Vera documentation to speak of. The only thing I’ve found to go on is here: [url=http://wiki.micasaverde.com/index.php/Luup_Lua_extensions#Module:_io]http://wiki.micasaverde.com/index.php/Luup_Lua_extensions#Module:_io[/url] and here: [url=http://wiki.micasaverde.com/index.php/Luup_Plugins_ByHand#.3Cprotocol.3E]http://wiki.micasaverde.com/index.php/Luup_Plugins_ByHand#.3Cprotocol.3E[/url]. The Vera/MiOS I/O model is particularly arcane.

1) It does not honor or process the tag in the device xml file.

No, it doesn't. I thought this was only an issue for serial I/O, but apparently not.

2) The IO routines appear to be designed for CRLF processing on incoming data, but does LF processing on outgoing data.

Ditto.

3) When luup.io.intercept is called, luup.io.read does not release the intercept, so normal processing never resumes. 4) When processing data after a call to luup.io.intercept, the IO routines stop processing incoming data.

This is the part I am not clear about, in particular what happens to the buffered data. Any further information you have on the way this is supposed to work would be most welcome. I have set up a new thread here: [url=http://forum.micasaverde.com/index.php/topic,35983.0.html]openLuup: Ademco Vista Alarm Panel with EVL3[/url] so that we can address the openLuup issues and not pollute this child board with irrelevancies.

Due to these incompatibilities, the "read panel" functions of the plugin will NOT operate.
If you manually configure the zones, the plugin should operate.

Can I add my thanks to those of @CudaNet: this is an exceptionally useful diagnosis, and openLuup will be made better because of it.

a-lurker · January 26, 2016, 9:25pm

The Vera/MiOS I/O model is particularly arcane.

Arcane - I’ll say. I spent a few days ploughing through this stuff trying to get a ip connection going. Turns out I had a function like so:

function processIncoming(msg) ... do stuff ... end

and so did another plugin!!

So wondering if any protection against accidental Global duplicate identifiers is possible in OpenLuup? Noting in this example, the function just had to be made local and it all worked there after.

While on the arcane aspects of mios, does any one fully understand how Jobs are meant to work? in particular the return codes.

akbooer · January 26, 2016, 9:34pm

[quote=“a-lurker, post:10, topic:190772”]Turns out I had a function like so:
…
and so did another plugin!![/quote]
This was on Vera, or openLuup?

While on the arcane aspects of mios, does any one fully understand how Jobs are meant to work? in particular the return codes.

I know exactly how I implemented it in openLuup, but I might be wrong.

Perhaps best to continue both these questions on an openLuup thread, rather than in the Ademco/EVL3 thread?

a-lurker · January 26, 2016, 10:53pm

Quote from: a-lurker on Today at 01:25:04 pm
Turns out I had a function like so:
...
and so did another plugin!!
This was on Vera, or openLuup?

This was on Vera.

RichardTSchaefer · February 6, 2016, 1:26am

Does each plugin instanced have it’s own Global LUA Name Space as it does on Vera ?
This is different from the Startup/Scene Gloval LUA Name Space ?

akbooer · February 6, 2016, 8:13am

By design, yes. So _G is different between devices, and different again from the_G which is shared between startup and scenes. However, unlike Vera, this is not done by running each device in a separate instance with two threads. That’s where all the memory goes in Vera, that’s why openLuup doesn’t do it. However, I may not have implemented it perfectly, it is a bit harder to do than it might seem in Lua 5.1.

Note that the problem described below, with a clash of names, appears to be on Vera, not openLuup.

We should carry on any further technical discussion on openLuup on a new thread on the openLuup child board, not here on the EVL3 one!