openLuup: Troubleshooting plugins

[martynwendon]

Thanks akbooer & vosmont (especially for that undocumented watch discovery!)

A couple more questions if that’s ok

I see quite a lot of calls for /cgi-bin/cmh/sysinfo.sh in the logs, which obviously doesn’t exist, is that expected?

Is there a list of known “working” plugins? Or is it a case of trying them and seeing for yourself? I’m using the Day Or Night and Heliotrope plugins so far without a problem.

If a plugin doesn’t work, what’s the best way to determine who to report that to? Is it an openLuup issue? Or an AltUI issue? Or maybe a a bit of both?

As an example I’m looking at the Visonic alarm panel plugin for my Powermax+ … I can workaround the lack of serial io by moving it to an ethernet interface or using socat so that’s not a problem.

But the plugin fails to load correctly at all initially, I fixed a couple of things easily enough (missing “bit” lib and a badly packaged ssl/https lib that was in the wrong place).

AltUI was showing errors in the parent device though, complaining of a missing function “pulldown_from_array”, I tracked that down to /mios/www/cmh/js/main.js on a real Vera so as a quick fix I just copied the function into the plugins’ own JS file.

Should that main.js file be part of openLuup though? Or AltUI? Or neither and it’s bad form for a plugin to rely on something from the core Vera files?

So the Visonic plugin is sort of running, but the UI is still a bit messed up with regards to settings and controls etc - I guess that’s an AltUI issue?

I’ll need to physically connect a Visonic panel to go much further (to see if it actually talks to the panel and creates all the child devices (partitions & sensors). I would need to break my live system to do that though so just wondering which direction to ask for help if it all fails spectacularly!

Thanks again,

Martyn

[akbooer]

@martynwendon

A couple more questions if that’s ok

Well, OK, but only because they’re good questions. In fact, they’re so good, that I’m starting a new thread with a better topic title since we have wandered far from the original here http://forum.micasaverde.com/index.php/topic,35656.msg263560.html#msg263560

I see quite a lot of calls for /cgi-bin/cmh/sysinfo.sh in the logs, which obviously doesn't exist, is that expected?

Yes, the thing that’s of note if that you’re seeing them (I think) in the log of the server on port 3480. This is because of a little magic that @amg0 made possible in this release http://forum.micasaverde.com/index.php/topic,33308.msg260309.html#msg260309 (that’s build 1023 and beyond) “sysinfo fix (openluup)”. This should mean that openLuup can handle CGI call as it likes (at least, in some cases.) I plan to have a /etc/cmh-ludl/cgi-bin/ directory where you can put scripts. This is a special case of something I’ll go into further below.

Is there a list of known "working" plugins? Or is it a case of trying them and seeing for yourself? I'm using the Day Or Night and Heliotrope plugins so far without a problem.

Not exactly, although @CudaNet has made a good start. What I have done is to create threads here with board topics such as ‘AV Plugins’ (actually mostly for audio: Sonos, DLNA, etc.) and ‘Video, Cameras’, etc. There’s even one for ‘Day or Night’.

I have to say that I don’t understand what the Day or Night plugin brings over and above the luup.is_night() call, along with the Night mode that UI7 introduced. I should perhaps also note that all the calculations that the Heliotrope plugin does are already in the timer module of openLuup, since that it exactly how it calculates sunrise and sunset. I can make these accessible, if needed, through the openLuup:Extensions plugin.

If a plugin doesn't work, what's the best way to determine who to report that to? Is it an openLuup issue? Or an AltUI issue? Or maybe a a bit of both?

If it’s a problem with the luup environment, then it’s an openLuup issue. Otherwise, it’s sometimes hard to tell. @amg0 and I discuss things a fair amount! If your can verify that it’s not a problem on Vera (under AltUI) then that’s a good start. Then ask either in an existing appropriate thread or start a new one. I like to prefix openLuup topics with “openLuup:…” to make it clear to the casual reader that it’s not a Vera topic (perhaps we need our own BB!)

On a more general point, I simply can’t be an expert on other people’s plugins. It’s quite amazing the things some developers do (quite understandably) to try and function in Vera’s weird ecosystem. However, openLuup is NOT Vera, and whilst it aspires to a very complete emulation of the Luup environment, Vera/MiOS is much more than that. In particular, there are script files all over the place, that some developers use to find out various things. Also, none of openLuup’s files are compressed, so folk who do wonderful things with call to pluto-lzo may run into trouble. I’m also keen on making as much of it work as possible under windws, so call to os.execute() should be eschewed. We can ask openLuup-friendly developers to tweak things a bit - or we can do it ourselves.

As an example I'm looking at the Visonic alarm panel plugin for my Powermax+ ... I can workaround the lack of serial io by moving it to an ethernet interface or using socat so that's not a problem.

I’d be interested to hear how that goes. It is, to me, the best solution to avoid having to handle hardware-specific serial devices in openLuup.

But the plugin fails to load correctly at all initially, I fixed a couple of things easily enough (missing "bit" lib and a badly packaged ssl/https lib that was in the wrong place).

These are things of general interest that I can highlight and improve upon in the documentation. It’s also why I included a configuration test utility in the openLuup distribution.

AltUI was showing errors in the parent device though, complaining of a missing function "pulldown_from_array", I tracked that down to /mios/www/cmh/js/main.js on a real Vera so as a quick fix I just copied the function into the plugins' own JS file.

Should that main.js file be part of openLuup though? Or AltUI? Or neither and it’s bad form for a plugin to rely on something from the core Vera files?

openLuup has not one line of JavaScript. Never has, never will. It actually has almost nothing to do with the user interface - that’s AltUI’s domain (and absolutely not an area of my expertise, such as it is.)

So the Visonic plugin is sort of running, but the UI is still a bit messed up with regards to settings and controls etc - I guess that's an AltUI issue?

I’ll need to physically connect a Visonic panel to go much further (to see if it actually talks to the panel and creates all the child devices (partitions & sensors). I would need to break my live system to do that though so just wondering which direction to ask for help if it all fails spectacularly!

Well, as you see after reading the above: it may, or may not, be an AltUI issue. Just ask again.

[amg0]

these are likely Altui issues,
ALTUI implements a imperfect compatiblity layer to run JS plugin tabs code but

• plugin JS code is wild, people use many undocumented features that they poke from the UIx code
• plugin use wild mix of framework ( prototype, underscore, old jquery ) etc
• some are encrypted
• ALTUI is multi controller and want to control several box at the same time, that means a mix of UI5 UI7 eventually openluup
  so there are unavoidable issues and I cannot garantee in ALTUI full compatiblity with all plugin code.
• I do not have the HW to test plugins

that being said, there is a number of defensive techniques that ALTUI applies to get some good compatiblity when possible

• J_ALTUI_api.js implements the UI5 and UI7 api with some misses somtime but that is the file where to put some “glue” layer that we need ( like missing functions, UI5 global that people use etc )
• ALTUI implements a context switch facility that gives a context to a JS plugin code with some predefined variables , such that the plugin code is still working despite there could be different / multiple backend controllers to work with
• very last resort but not least ; if the plugin code uses a js framework that ALTUI is not loading ( I am not going to load them all ) , I modify the plugin source code on the fly at the time of loading it => thus sometime generating bug , hard to debug but is the price to pay

So , our only chance to increase compatiblity is people like you , debugging identifying issues and submitting code to me , I ll integrate it

hope that helps

[martynwendon]

Thanks again akbooer, seems to me that openLuup should gain some more traction if the plugin devs get on board!

@akbooer

I plan to have a /etc/cmh-ludl/cgi-bin/ directory where you can put scripts.

That sounds good, should be pretty trivial to rework sysinfo.sh to provide something meaningful on an openLuup install.

@akbooer

Not exactly, although @CudaNet has made a good start.

I think a list would be good to have, then we can submit updates and hopefully prompt other devs to get their plugins compatible.

@akbooer

I have to say that I don’t understand what the Day or Night plugin brings over and above the luup.is_night() call, along with the Night mode that UI7 introduced.

For me it’s mainly legacy so that I can use it as a Trigger in a Scene as a simple on / off. My main Vera is still on UI5 so it was the easy option

@akbooer

I should perhaps also note that all the calculations that the Heliotrope plugin does are already in the timer module of openLuup, since that it exactly how it calculates sunrise and sunset. I can make these accessible, if needed, through the openLuup:Extensions plugin.

That would be interesting as it would mean one less plugin. For my own purposes I just “watch” RightAscension, Declination, Azimuth and Altitude variables for use in my own plugin.

@akbooer

If it’s a problem with the luup environment, then it’s an openLuup issue. Otherwise, it’s sometimes hard to tell. @amg0 and I discuss things a fair amount! If your can verify that it’s not a problem on Vera (under AltUI) then that’s a good start.

OK, that sounds doable, will just need to setup a Vera victim for testing with and go from there - not keen on doing testing on Live system obviously

@akbooer

On a more general point, I simply can’t be an expert on other people’s plugins. It’s quite amazing the things some developers do (quite understandably) to try and function in Vera’s weird ecosystem.

I hear ya! I’ve seen some of the stuff mentioned in the other thread with calls out to Linux stuff like opkg … frightening IMO and definitely makes me think twice about touching any plugin until I’ve done some checking on what it might be doing under the hood!

I do like the openness of Vera in general but the fact that this sort of stuff is still possible even in current versions is scary - plugins should be sandboxed at a minimum and direct external calls should be disallowed completely (or made accessible through a proper LUA library). But we are where we are …

@akbooer

We can ask openLuup-friendly developers to tweak things a bit - or we can do it ourselves.

I guess this is where we’re at now, so hopefully raising awareness of openLuup will help with that.

@akbooer

I’d be interested to hear how that goes. It is, to me, the best solution to avoid having to handle hardware-specific serial devices in openLuup.

I don’t see it being a problem, as far as I know it’s how Vera does it under the hood with ser2net anyway.

@akbooer

These are things of general interest that I can highlight and improve upon in the documentation. It’s also why I included a configuration test utility in the openLuup distribution.

Yeah some of this will be platform dependent and also depend on what plugins are being used. Documentation currently is pretty much spot on though, I certainly didn’t have any issues getting up and running, although I have been a Linux geek for 20 odd years though, so that helps!

Oh, while I remember I did spot an issue with one of the symlinks though on page 5 in step 2.C - don’t think “device_states” should be in the end unless it’s the intention to create a symlink to something that may appear at a later date?

Would also like to see a proper stop / start / reload init.d script so will figure something out for that and report back. Just makes it easier IMO to be able to control from command line, plus for things like Nagios or Monit to restart it if it ever goes down … not that it ever will though by the sounds of it ;D

@akbooer

Well, as you see after reading the above: it may, or may not, be an AltUI issue. Just ask again.

Will do, I’ve seen enough already to decide it warrants further effort so I’ll hopefully pickup a spare Visonic panel and interface to experiment with … a bit of a cost but saves me messing with my Live system.

[martynwendon]

[quote=“amg0, post:3, topic:190487”]these are likely Altui issues,
So , our only chance to increase compatiblity is people like you , debugging identifying issues and submitting code to me , I ll integrate it

hope that helps[/quote]

Well it seems a pretty awesome achievement so far given all that is going on under-the-hood

Is it ok to continue the discussion for Visonic specifically here, or would you prefer under the AltUI board?

I’m not certain but I think the Visonic plugin is no longer maintained / developed, so not sure this is one where we’d get much help for AltUI / openLuup changes

[akbooer]

@martynwendon

Would also like to see a proper stop / start / reload init.d script so will figure something out for that and report back.

Yes, that’s a ‘must have’. I think @CudaNet may have something along these lines?

[CudaNet]

At first I did but I’ve found it kind of unnecessary for my needs. This system is just too damn stable ! Any administration I do is performed at the CL after halting the engine. Once done then I simply reboot and let rc.local start everything back up. Oh, I forgot to mention that I almost never perform administration. It’s beautiful !

@akbooer

[quote=“martynwendon, post:4, topic:190487”]Would also like to see a proper stop / start / reload init.d script so will figure something out for that and report back.

Yes, that’s a ‘must have’. I think @CudaNet may have something along these lines?[/quote]

[martynwendon]

@CudaNet

Once done then I simply reboot and let rc.local start everything back up.

reboot a linux box? pah, it’s not windoze ;D

root@ahsrpi2:~# uptime 20:16:36 up 1159 days, 3:31, 1 user, load average: 0.05, 0.04, 0.05

[CudaNet]

I think you meant, it’s not Vera. I’m really working hard on my reverse therapy… Must not unplug, must not reboot …

@martynwendon

[quote=“CudaNet, post:7, topic:190487”]Once done then I simply reboot and let rc.local start everything back up.

reboot a linux box? pah, it’s not windoze ;D

root@ahsrpi2:~# uptime 20:16:36 up 1159 days, 3:31, 1 user, load average: 0.05, 0.04, 0.05[/quote]

[akbooer]

@martynwendon

[quote=“akbooer, post:2, topic:190487”]I plan to have a /etc/cmh-ludl/cgi-bin/ directory where you can put scripts.

That sounds good, should be pretty trivial to rework sysinfo.sh to provide something meaningful on an openLuup install.[/quote]

…so continuing the story, some six weeks later, the current Release 7 candidate now supports WSAPI applications as CGIs. This means that it’s trivial, indeed, to implement what you want here. Just create the above directory and follow the instructions here on writing a WSAPI application. By way of example, I attach a skeleton CGI which simply sends a fixed text (slightly modified version of what my Vera Edge reports for this CGI.)

You can see the output of the CGI by accessing it through port 3480:

http://openLuupIP:3480/cgi-bin/cmh/sysinfo.sh

Hope this helps.

[martynwendon]

Sounds cool, I’m going to be migrating my existing openLuup install to a permanent device (Odroid XU4) in the next few weeks so will take a look at updating to the latest RC at the same time. Kinda loathe to mess with the current install as it’s been working so well ;D