We have moved at community.getvera.com

Author Topic: Different behaviour for handlers  (Read 3664 times)

Offline reneboer

  • Beta Testers
  • Hero Member
  • *****
  • Posts: 1574
  • Karma: +110/-31
Different behaviour for handlers
« on: February 09, 2016, 05:20:40 pm »
Hi akbooer,

I am trying to get my Harmony Hub plug in running on openLuup and it is sure not a trivial exercise. Besides having the same challenges as Multi Switch as I rewrite the json and D..xml files I was banging my head on getting the settings working.

What I found is that the way openLuup deals with handers is different. First the name of the passed request. Vera strips the 'lr_' from the lul_request parameter.

I also found that the hander runs not in the same code space as the plugin but on level 0 as you can see in this log. This seems to be causing issues with anything I try with a call_delay() to result in an unknow function error.

Code: [Select]
2016-02-09 23:09:22.608   luup.register_handler:14: global_function_name=HTTP_HarmonyInt, request=lr_hamGetActivities14
2016-02-09 23:09:22.609   luup.register_handler:14: global_function_name=HTTP_HarmonyInt, request=lr_hamGetDevices14
2016-02-09 23:09:22.609   luup.register_handler:14: global_function_name=HTTP_HarmonyInt, request=lr_hamGetDeviceCommands14
2016-02-09 23:09:22.610   luup_log:14: HARMM Harmony Control: Harmony_CreateChildren for device
2016-02-09 23:09:31.464   openLuup.server:: /data_request/data_request?id=lr_hamGetActivities14&serviceId=urn%3Arboer-com%3AserviceId%3AHarmony1&DeviceNum=14&timestamp=1455055770933&HID=&output_format=json tcp{client}: 0x6ea470
2016-02-09 23:09:31.466   luup.variable_set:0: 14.urn:rboer-com:serviceId:Harmony1.IconSet was: 0 now: 2 #hooks:0
2016-02-09 23:09:31.467   luup_log:0: HARMM Harmony Control: request is: lr_hamGetActivities14
2016-02-09 23:09:31.467   luup_log:0: HARMM Harmony Control: outputformat is: json

Can you make this behave more like Vera? Or am I doing something wrong that Vera accepts, but is bad coding?

Cheers Rene
2xVeraLite, VeraEdge, openLuup, ALTUI, 20 switches, 10 dimmers, 20 sensors, 10 scene controllers, 1 Harmony Hub, many plug-ins. Not enough time.

Offline akbooer

  • Moderator
  • Master Member
  • *****
  • Posts: 6387
  • Karma: +291/-70
  • "Less is more"
Re: Different behaviour for handlers
« Reply #1 on: February 09, 2016, 06:51:38 pm »
First the name of the passed request. Vera strips the 'lr_' from the lul_request parameter.

You mean in the first parameter of the callback handler?  I'll check it out.  I only ever use a one-to-one mapping of requests and handlers, so I've not run across that myself.  Easily fixed.

Quote
I also found that the hander runs not in the same code space as the plugin but on level 0 as you can see in this log.

Yes, a known issue (to me) which doesn't usually cause problems. I'll work harder on fixing it.

Quote
This seems to be causing issues with anything I try with a call_delay() to result in an unknow function error.

You use call_delay in callback handlers ?!!  :o

Quote
Can you make this behave more like Vera?

Yes, assuredly.  But I can only fix one error at a time... did the attribute fix work OK?
3x Vera Lite-UI5/Edge-UI7, 25x Fibaro, 23x TKB, 9x MiniMote, 2x NorthQ Power, 2x Netatmo, 1x Foscam FI9831P, 9x Philips Hue,
Razberry, MySensors Arduino, HomeWave, AltUI, AltHue, DataYours, Grafana, openLuup, ZWay, ZeroBrane Studio.

Offline reneboer

  • Beta Testers
  • Hero Member
  • *****
  • Posts: 1574
  • Karma: +110/-31
Re: Different behaviour for handlers
« Reply #2 on: February 10, 2016, 05:10:45 am »
First the name of the passed request. Vera strips the 'lr_' from the lul_request parameter.

You mean in the first parameter of the callback handler?  I'll check it out.  I only ever use a one-to-one mapping of requests and handlers, so I've not run across that myself.  Easily fixed.

Correct, first parameter. I prefer having as little entry point into my code as possible. All personal coding preferences I suppose.
Quote
I also found that the hander runs not in the same code space as the plugin but on level 0 as you can see in this log.

Yes, a known issue (to me) which doesn't usually cause problems. I'll work harder on fixing it.

Quote
This seems to be causing issues with anything I try with a call_delay() to result in an unknow function error.

You use call_delay in callback handlers ?!!  :o
Yes as I run an http request to the Harmony Hub from the handlers I use those to not lockup the tread for too long. I have worked around it for openLuup as that seems less sensitive to it and much faster in handling the resonses.

Quote
Can you make this behave more like Vera?

Yes, assuredly.  But I can only fix one error at a time... did the attribute fix work OK?
Great. And yes that seems to be working now.
2xVeraLite, VeraEdge, openLuup, ALTUI, 20 switches, 10 dimmers, 20 sensors, 10 scene controllers, 1 Harmony Hub, many plug-ins. Not enough time.

Offline akbooer

  • Moderator
  • Master Member
  • *****
  • Posts: 6387
  • Karma: +291/-70
  • "Less is more"
Re: Different behaviour for handlers
« Reply #3 on: February 10, 2016, 08:25:21 am »
The GitHub development branch https://github.com/akbooer/openLuup/tree/development/openLuup has a fix for both the callback context and request parameter name. 

I've tested with a luup.call_delay() in the handler and it seems to work fine now.  Thanks for the encouragement to fix this at last!

If you say it's OK for you, then I'll merge with the master branch.
3x Vera Lite-UI5/Edge-UI7, 25x Fibaro, 23x TKB, 9x MiniMote, 2x NorthQ Power, 2x Netatmo, 1x Foscam FI9831P, 9x Philips Hue,
Razberry, MySensors Arduino, HomeWave, AltUI, AltHue, DataYours, Grafana, openLuup, ZWay, ZeroBrane Studio.

Offline reneboer

  • Beta Testers
  • Hero Member
  • *****
  • Posts: 1574
  • Karma: +110/-31
Re: Different behaviour for handlers
« Reply #4 on: February 10, 2016, 05:33:53 pm »
Hi akbooer,

Works like a charm. Thanks for the quick reply.

Cheers Rene
2xVeraLite, VeraEdge, openLuup, ALTUI, 20 switches, 10 dimmers, 20 sensors, 10 scene controllers, 1 Harmony Hub, many plug-ins. Not enough time.

Offline akbooer

  • Moderator
  • Master Member
  • *****
  • Posts: 6387
  • Karma: +291/-70
  • "Less is more"
Re: Different behaviour for handlers
« Reply #5 on: February 10, 2016, 05:45:16 pm »
Excellent! 

Did you mention a while ago that you had a similar issue with files loaded by require ?
3x Vera Lite-UI5/Edge-UI7, 25x Fibaro, 23x TKB, 9x MiniMote, 2x NorthQ Power, 2x Netatmo, 1x Foscam FI9831P, 9x Philips Hue,
Razberry, MySensors Arduino, HomeWave, AltUI, AltHue, DataYours, Grafana, openLuup, ZWay, ZeroBrane Studio.

Offline reneboer

  • Beta Testers
  • Hero Member
  • *****
  • Posts: 1574
  • Karma: +110/-31
Re: Different behaviour for handlers
« Reply #6 on: February 10, 2016, 06:03:04 pm »
Nope, not me. Just got started with a Pi last Saturday.  ;D

Cheers Rene
2xVeraLite, VeraEdge, openLuup, ALTUI, 20 switches, 10 dimmers, 20 sensors, 10 scene controllers, 1 Harmony Hub, many plug-ins. Not enough time.

Offline ronluna

  • Jr. Member
  • **
  • Posts: 96
  • Karma: +1/-3
Re: Different behaviour for handlers
« Reply #7 on: February 10, 2016, 11:03:35 pm »
@reneboer does this means Harmony plugin is able to run on your openluup setup?  :o

Offline reneboer

  • Beta Testers
  • Hero Member
  • *****
  • Posts: 1574
  • Karma: +110/-31
Re: Different behaviour for handlers
« Reply #8 on: February 11, 2016, 04:44:40 am »
@reneboer does this means Harmony plugin is able to run on your openluup setup?  :o
Almost. Only triggers I cannot get working yet. I will let you know.

Cheers Rene
2xVeraLite, VeraEdge, openLuup, ALTUI, 20 switches, 10 dimmers, 20 sensors, 10 scene controllers, 1 Harmony Hub, many plug-ins. Not enough time.

Offline akbooer

  • Moderator
  • Master Member
  • *****
  • Posts: 6387
  • Karma: +291/-70
  • "Less is more"
Re: Different behaviour for handlers
« Reply #9 on: February 11, 2016, 05:41:08 am »
Only triggers I cannot get working yet. I will let you know.

Be aware that openLuup does not implement Vera triggers or notifications, but relies on AltUI device watches to provide similar (actually better) functionality.  From a programming point of view, however, this means that JSON-encoded definitions of scenes added through an HTTP request will simply not have their triggers stored.  You may, instead, do what AltUI does and use luup.variable_watch() to construct your own triggers.
3x Vera Lite-UI5/Edge-UI7, 25x Fibaro, 23x TKB, 9x MiniMote, 2x NorthQ Power, 2x Netatmo, 1x Foscam FI9831P, 9x Philips Hue,
Razberry, MySensors Arduino, HomeWave, AltUI, AltHue, DataYours, Grafana, openLuup, ZWay, ZeroBrane Studio.

Offline reneboer

  • Beta Testers
  • Hero Member
  • *****
  • Posts: 1574
  • Karma: +110/-31
Re: Different behaviour for handlers
« Reply #10 on: February 11, 2016, 07:14:01 am »
Only triggers I cannot get working yet. I will let you know.

Be aware that openLuup does not implement Vera triggers or notifications, but relies on AltUI device watches to provide similar (actually better) functionality.  From a programming point of view, however, this means that JSON-encoded definitions of scenes added through an HTTP request will simply not have their triggers stored.  You may, instead, do what AltUI does and use luup.variable_watch() to construct your own triggers.
Aha, ok I'll have a look at that then and add it to the documentation.

Cheers Rene
2xVeraLite, VeraEdge, openLuup, ALTUI, 20 switches, 10 dimmers, 20 sensors, 10 scene controllers, 1 Harmony Hub, many plug-ins. Not enough time.

Offline vosmont

  • Beta Testers
  • Hero Member
  • *****
  • Posts: 687
  • Karma: +60/-8
Re: Different behaviour for handlers
« Reply #11 on: February 11, 2016, 09:10:11 am »
Excellent! 

Did you mention a while ago that you had a similar issue with files loaded by require ?

It was me :)

Offline akbooer

  • Moderator
  • Master Member
  • *****
  • Posts: 6387
  • Karma: +291/-70
  • "Less is more"
Re: Different behaviour for handlers
« Reply #12 on: February 11, 2016, 10:00:55 am »
yes, thought so, and looked for the comment, but couldn't find.

Can you elaborate?
3x Vera Lite-UI5/Edge-UI7, 25x Fibaro, 23x TKB, 9x MiniMote, 2x NorthQ Power, 2x Netatmo, 1x Foscam FI9831P, 9x Philips Hue,
Razberry, MySensors Arduino, HomeWave, AltUI, AltHue, DataYours, Grafana, openLuup, ZWay, ZeroBrane Studio.

Offline vosmont

  • Beta Testers
  • Hero Member
  • *****
  • Posts: 687
  • Karma: +60/-8
Re: Different behaviour for handlers
« Reply #13 on: February 11, 2016, 10:35:40 am »
I think it's here : http://forum.micasaverde.com/index.php/topic,35656.msg263642.html#msg263642

The code loaded by "require" has it own global environment (just string, table and some other objects that are shared).
If you defined a global variable in the startup of your plugin, it won't be available in the loaded code.

implementation file :
Code: [Select]
<?xml version="1.0"?>
<implementation>
<functions>
function startup (lul_device)
myLib = require("L_myLib1")
end
</functions>
<startup>startup</startup>

L_myLib1.lua
Code: [Select]
module("L_myLib1", package.seeall)

require("L_myLib2")

L_myLib2.lua
Code: [Select]
module("L_myLib2", package.seeall)

-- In openLuup, the module myLib1 loaded during the startup sequence is in a dedicated environment.
-- In legacy Vera, the global variables defined in stratup sequence are global everywhere
local myLib = L_myLib1 or myLib

I don't know if it's normal (it seems to be the default behaviour of require) but in Vera, it's possible.
I have found a workaround with "L_PluginName"

Offline akbooer

  • Moderator
  • Master Member
  • *****
  • Posts: 6387
  • Karma: +291/-70
  • "Less is more"
Re: Different behaviour for handlers
« Reply #14 on: February 12, 2016, 10:48:49 am »
For me, it doesn't seem like a good plan to have modules accessing the global environment.  Of course, I invariably do use "package.seeall" but only to access the usual Lua system modules and the Luup environment. 

I assume that 'require' uses somewhere 'loadstring' and that is not, by default, using the caller's context in openLuup.  I may see if I can fix this.

You should be aware, however, that in openLuup, the 'module' call is a no-op, and only there for compatibility with Vera code.  Outside of the Vera environment, the 'module' keyword is now deprecated (in versions of Lua beyond 5.1) , since it's really not needed.
3x Vera Lite-UI5/Edge-UI7, 25x Fibaro, 23x TKB, 9x MiniMote, 2x NorthQ Power, 2x Netatmo, 1x Foscam FI9831P, 9x Philips Hue,
Razberry, MySensors Arduino, HomeWave, AltUI, AltHue, DataYours, Grafana, openLuup, ZWay, ZeroBrane Studio.