openLuup: Harmony Hub plugin v2.6

Plugins & Plugin Development openLuup
1

Hi,

You can get the files from GitHub [url=https://github.com/reneboer/vera-Harmony-Hub]https://github.com/reneboer/vera-Harmony-Hub[/url].

I updated the Harmony Hub plugin so it can run on the latest version of openLuup [url=https://github.com/akbooer/openLuup]https://github.com/akbooer/openLuup[/url]. There are some fixes from a few days old, so make sure you update openLuup.

Thanks to Akbooer for fixing the minor things I found so quickly and pointing me in the right directions for others.

PS: If you use VeraBridge you cannot control the Harmony Plugin via an other machine (openLuup or other Vera) this is because the files and device types get modified to support multiple local copies. I have to see if I can fix that as it does work for MultiSwitch. But as you can setup multiple copies of the plugin on each machine that can do exactly the same it is not a priority for me.

Cheers Rene

2

I must have missed this post… This is awesome - thanks for updating the plugin (and posting them on Git). I’ll install this later this week and give it a go as my wife loves having control over her candles throughout the house.
Again - much appreciated…

CN

[quote=“reneboer, post:1, topic:191023”]Hi,

You can get the files from GitHub [url=https://github.com/reneboer/vera-Harmony-Hub]https://github.com/reneboer/vera-Harmony-Hub[/url].

I updated the Harmony Hub plugin so it can run on the latest version of openLuup [url=https://github.com/akbooer/openLuup]https://github.com/akbooer/openLuup[/url]. There are some fixes from a few days old, so make sure you update openLuup.

Thanks to Akbooer for fixing the minor things I found so quickly and pointing me in the right directions for others.

PS: If you use VeraBridge you cannot control the Harmony Plugin via an other machine (openLuup or other Vera) this is because the files and device types get modified to support multiple local copies. I have to see if I can fix that as it does work for MultiSwitch. But as you can setup multiple copies of the plugin on each machine that can do exactly the same it is not a priority for me.

Cheers Rene[/quote]

3

@reneboer

Installed the plugin tonight, configured the IP address and credentials. Created a child device for the Luminara candle, configured the buttons (on and off). Everything appears in order.
When attempting to enable the candle, the logs indicate:

2016-02-17 23:14:14.655   openLuup.server:: /data_request?id=action&output_format=json&DeviceNum=28&serviceId=urn:rboer-com:serviceId:HarmonyDevice1&action=SendDeviceCommand&Command=PowerOn tcp{client}: 0xfa1500
2016-02-17 23:14:14.657   luup.variable_set:0: 5.openLuup.Memory_Mb was: 4 now: 4 #hooks:0
2016-02-17 23:14:14.658   luup.variable_set:0: 5.openLuup.Cpu_2m was: 0 now: 0 #hooks:0
2016-02-17 23:14:14.659   luup.variable_set:0: 5.openLuup.CpuLoad_Percent was: 0 now: 0 #hooks:0
2016-02-17 23:14:14.661   luup.variable_set:0: 5.openLuup.CpuLoad_Hours was: 0 now: 0 #hooks:0
2016-02-17 23:14:14.662   luup.variable_set:0: 5.openLuup.Uptime_Days was: 2.57 now: 2.57 #hooks:0
2016-02-17 23:14:14.663   luup.variable_set:0: 5.urn:upnp-org:serviceId:altui1.DisplayLine1 was: Uptime 2.57 days now: Uptime 2.57 days #hooks:0
2016-02-17 23:14:14.665   luup.variable_set:0: 5.urn:upnp-org:serviceId:altui1.DisplayLine2 was: Memory 4 Mb,  CPU 0 % now: Memory 4 Mb,  CPU 0 % #hooks:0
2016-02-17 23:14:14.666   luup_log:0: openLuup PLUGIN memory: 4.0 Mb, uptime: 2.57 days, cpu: 0.00 hours (0.0%)
2016-02-17 23:14:14.667   luup.call_action:0: 28.urn:rboer-com:serviceId:HarmonyDevice1.SendDeviceCommand 
2016-02-17 23:14:14.669   openLuup.server:: request completed (70 bytes, 1 chunks, 14 ms) tcp{client}: 0xfa1500
2016-02-17 23:14:14.671   luup.variable_set:0: 5.openLuup.Memory_Mb was: 4 now: 4 #hooks:0
2016-02-17 23:14:14.672   luup.variable_set:0: 5.openLuup.Cpu_2m was: 0 now: 0 #hooks:0
2016-02-17 23:14:14.673   luup.variable_set:0: 5.openLuup.CpuLoad_Percent was: 0 now: 0 #hooks:0
2016-02-17 23:14:14.674   luup.variable_set:0: 5.openLuup.CpuLoad_Hours was: 0 now: 0 #hooks:0
2016-02-17 23:14:14.676   luup.variable_set:0: 5.openLuup.Uptime_Days was: 2.57 now: 2.57 #hooks:0
2016-02-17 23:14:14.677   luup.variable_set:0: 5.urn:upnp-org:serviceId:altui1.DisplayLine1 was: Uptime 2.57 days now: Uptime 2.57 days #hooks:0
2016-02-17 23:14:14.678   luup.variable_set:0: 5.urn:upnp-org:serviceId:altui1.DisplayLine2 was: Memory 4 Mb,  CPU 0 % now: Memory 4 Mb,  CPU 0 % #hooks:0
2016-02-17 23:14:14.680   luup_log:0: openLuup PLUGIN memory: 4.0 Mb, uptime: 2.57 days, cpu: 0.00 hours (0.0%)
2016-02-17 23:14:14.680   openLuup.context_switch::  ERROR: [string "[28] I_HarmonyDevice.xml"]:8: attempt to call global 'Harmony_SendDeviceCommand' (a nil value)
2016-02-17 23:14:14.681   openLuup.scheduler:: job aborted : [string "[28] I_HarmonyDevice.xml"]:8: attempt to call global 'Harmony_SendDeviceCommand' (a nil value)

Used latest files off Git. Let me know what other details you require…

Thanks

4

Hi CudaNet,

I ran into that yesterday too. There is a difference in how openLuup seems to work with child devices. At the same time I remember a discussion on the scope of variables some months ago (on standard Vera) and some where surprised it worked for me at all. So I may be doing something sub-optimal, but the Vera does handle it.

Basically I have the hander for Harmony_SendDeviceCommand in the LUA for the parent device with the option 1 in the implementation file of the parent device.

The implementation file for the child devices I_HarmonyDevice.xml have the action defined but no other code or files included.

<action> <serviceId>urn:rboer-com:serviceId:HarmonyDevice1</serviceId> <name>UpdateDeviceButtons</name> <job> Harmony_UpdateDeviceButtons(lul_device) return 4,nil </job> <jobname>UpdateDeviceButtons</jobname> </action>

As said this work fine on a Vera, but not on openLuup.

Should I put the actions in the parent implementation and not have an implementation file for child devices? When I try this on openLuup, the variables set as local in the parent LUA are not defined when calling from the child device. So how this should be properly coded? Advice is welcome.

As a workaround you can change the variable Version and restart luup. That will generate the files correctly. this is why I did not notice the problem initially.

Cheers Rene

5

Hi CudaNet,

I think I cracked it at last. Have no implementation file for the child devices and put handleChildren in the device file, not the implementation file.

I will do some more testing, also on Vera and update GitHub if it indeed works.

Cheers Rene

6

I think OpenLuup only looks in one of those places for handleChildren, so that can be easily fixed.

7

I think OpenLuup only looks in one of those places for handleChildren, so that can be easily fixed.[/quote]
I looked up that old discussion on child handling and handleChildren in the implementation file does nothing on a Vera either. For some odd reason, however you can have a child implementation file calling functions from the parent implementation file without properly defining handleChildren. I doubt that is expected behavior and by cleaning up my device and implementation files it is now working. It was the strange Vera behavior that has thrown me off all this time (and probably bad examples and lack of documentation) and the proper openLuup handling now set me straight :smiley:

Cheers Rene

8

Ah, thanks - I’ll not make the change then (was just about to press the Commit button on GitHub!)

9

Thanks Rene, I’ll keep an eye out for any updates… Glad you were able to reproduce the issue and it sounds like you’re making progress. Let me know if I can help test.

[quote=“reneboer, post:5, topic:191023”]Hi CudaNet,

I think I cracked it at last. Have no implementation file for the child devices and put handleChildren in the device file, not the implementation file.

I will do some more testing, also on Vera and update GitHub if it indeed works.

Cheers Rene[/quote]

10

[quote=“CudaNet, post:9, topic:191023”]Thanks Rene, I’ll keep an eye out for any updates… Glad you were able to reproduce the issue and it sounds like you’re making progress. Let me know if I can help test.

[quote=“reneboer, post:5, topic:191023”]Hi CudaNet,

I think I cracked it at last. Have no implementation file for the child devices and put handleChildren in the device file, not the implementation file.

I will do some more testing, also on Vera and update GitHub if it indeed works.

Cheers Rene[/quote][/quote]
Hi CudaNet,

I just posted the 2.6.1 version with the fixes on GitHub. Please let me know how that works for you.

Cheers Rene

11

Thanks, I’ll provided an update tonight…

[quote=“reneboer, post:10, topic:191023”][quote=“CudaNet, post:9, topic:191023”]Thanks Rene, I’ll keep an eye out for any updates… Glad you were able to reproduce the issue and it sounds like you’re making progress. Let me know if I can help test.

[quote=“reneboer, post:5, topic:191023”]Hi CudaNet,

I think I cracked it at last. Have no implementation file for the child devices and put handleChildren in the device file, not the implementation file.

I will do some more testing, also on Vera and update GitHub if it indeed works.

Cheers Rene[/quote][/quote]
Hi CudaNet,

I just posted the 2.6.1 version with the fixes on GitHub. Please let me know how that works for you.

Cheers Rene[/quote]

12

@reneboer

Tested and works perfect… Thank you for the update

13

[quote=“CudaNet, post:12, topic:191023”]@reneboer

Tested and works perfect… Thank you for the update[/quote]
Thanks for the update. Glad to hear.

Cheers Rene