We have moved at community.getvera.com

Author Topic: openLuup: AV plugins  (Read 32363 times)

Offline CudaNet

  • Beta Testers
  • Hero Member
  • *****
  • Posts: 1401
  • Karma: +42/-11
  • Chimichanga !
Re: openLuup: AV plugins
« Reply #30 on: November 11, 2015, 09:04:33 am »
Yes, device 10 is indeed a Sonos (Amp). For this test, all I have installed (well, with exception of openLuup ext.) are 5 Sonos devices. Odd that device 10 is complaining when I'm not even sending an action to it.
Sorry for being vague at that late of an hour, should have just called it quits and revisited it when I'm thinking clearly.

Very hard to debug with a full system And so little information.  What is device #10 in this case?  It looks like the Sonos is #7?
openLuup, AltUI, Zway and HomeWave, enough said...

Offline CudaNet

  • Beta Testers
  • Hero Member
  • *****
  • Posts: 1401
  • Karma: +42/-11
  • Chimichanga !
Re: openLuup: AV plugins
« Reply #31 on: November 11, 2015, 09:41:03 am »
Disregard my craziness... The URL I was referring too in my sleep deprivation was the speech server URL.
I've pruned the config down to a single Sonos device, all is working - meaning TTS and music. Reloaded and it holds up until I halt the engine/reboot the server.

I had the Sonos debug logs on and they are thick ! It's trying to speak, even pauses the music temporarily...
Will post them when I get to work..

And then I checked the URL and changed it from [http://10.0.3.11:8080/] to this  [http://10.0.3.11:8080]...
And then there was perfect speech...

Can you confirm on your end if this corrects anything. I do still see the message though...


Which URL would that be?
« Last Edit: November 11, 2015, 09:46:39 am by CudaNet »
openLuup, AltUI, Zway and HomeWave, enough said...

Offline akbooer

  • Moderator
  • Master Member
  • *****
  • Posts: 6387
  • Karma: +291/-70
  • "Less is more"
Re: openLuup: AV plugins
« Reply #32 on: November 11, 2015, 11:21:49 am »
I'm not sure what the sequence of events was when you generated all this, but I do see this:

Code: [Select]
2015-11-11 08:36:54.142   openLuup.server:: /data_request?id=lr_ALTUI_Handler&command=oscommand&oscommand=&_=1447252519655 tcp{client}: 0x233e4a8
2015-11-11 08:36:54.142   luup_log:3: ALTUI: ALTUI_Handler: request is: lr_ALTUI_Handler
2015-11-11 08:36:54.142   luup_log:3: ALTUI: ALTUI_Handler: parameters is: {"command":"oscommand","_":"1447252519655"}
2015-11-11 08:36:54.143   luup_log:3: ALTUI: ALTUI_Handler: outputformat is: null
2015-11-11 08:36:54.143   openLuup.context_switch::  ERROR: [string "device_3"]:106: bad argument #1 to 'gsub' (string expected, got nil)
2015-11-11 08:36:54.143   openLuup.server:: error in callback: lr_ALTUI_Handler, error is [string "device_3"]:106: bad argument #1 to 'gsub' (string expected, got nil)

...which looks like you tried to execute an empty Lua Test window in AltUI.

So there's obviously more than Sonos stuff happening in this time interval.
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 CudaNet

  • Beta Testers
  • Hero Member
  • *****
  • Posts: 1401
  • Karma: +42/-11
  • Chimichanga !
Re: openLuup: AV plugins
« Reply #33 on: November 11, 2015, 12:26:47 pm »
I don't recall executing an empty Lua window..
I was looking at the log data and I noticed this occurred many times within failed 'http://0.0.0.0:80/Say.4.mp3'. Although I never see it in the success log.

Does this seem right to you ? Their all over the failed log...

Code: [Select]
-- Failed Log
2015-11-11 08:36:03.073   luup_log:4: Sonos: debug: UPnP_request: status=1 statusMsg=200 result=[<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/" s:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"><s:Body><u:GetVolumeResponse xmlns:u="urn:schemas-upnp-org:service:RenderingControl:1"><CurrentVolume>32</CurrentVolume></u:GetVolumeResponse></s:Body></s:Envelope>]
2015-11-11 08:36:03.073   luup.variable_set:4: 4.urn:micasaverde-com:serviceId:HaDevice1.LastUpdate was: 1447252552 now: 1447252563 #hooks:0
2015-11-11 08:36:03.074   luup_log:4: Sonos: debug: uri: http://0.0.0.0:80/Say.4.mp3
2015-11-11 08:36:03.074   luup_log:4: Sonos: debug: uriMetaData:
2015-11-11 08:36:03.074   luup_log:4: Sonos: debug: service.__index: Accessing non-existing function SetAVTransportURI
2015-11-11 08:36:03.074   luup_log:4: Sonos: debug: SetAVTransportURI('http://10.0.4.20:1400/MediaRenderer/AVTransport/Control', 'urn:schemas-upnp-org:service:AVTransport:1') Called with parameter count=1
2015-11-11 08:36:03.074   luup_log:4: Sonos: debug: UPnP_request: url=[http://10.0.4.20:1400/MediaRenderer/AVTransport/Control], body=[<?xml version="1.0" encoding="utf-8"?>

I'm not sure what the sequence of events was when you generated all this, but I do see this:

Code: [Select]
2015-11-11 08:36:54.142   openLuup.server:: /data_request?id=lr_ALTUI_Handler&command=oscommand&oscommand=&_=1447252519655 tcp{client}: 0x233e4a8
2015-11-11 08:36:54.142   luup_log:3: ALTUI: ALTUI_Handler: request is: lr_ALTUI_Handler
2015-11-11 08:36:54.142   luup_log:3: ALTUI: ALTUI_Handler: parameters is: {"command":"oscommand","_":"1447252519655"}
2015-11-11 08:36:54.143   luup_log:3: ALTUI: ALTUI_Handler: outputformat is: null
2015-11-11 08:36:54.143   openLuup.context_switch::  ERROR: [string "device_3"]:106: bad argument #1 to 'gsub' (string expected, got nil)
2015-11-11 08:36:54.143   openLuup.server:: error in callback: lr_ALTUI_Handler, error is [string "device_3"]:106: bad argument #1 to 'gsub' (string expected, got nil)

...which looks like you tried to execute an empty Lua Test window in AltUI.

So there's obviously more than Sonos stuff happening in this time interval.
« Last Edit: November 11, 2015, 12:28:46 pm by CudaNet »
openLuup, AltUI, Zway and HomeWave, enough said...

Offline akbooer

  • Moderator
  • Master Member
  • *****
  • Posts: 6387
  • Karma: +291/-70
  • "Less is more"
Re: openLuup: AV plugins
« Reply #34 on: November 11, 2015, 12:36:14 pm »
I was looking at the log data and I noticed this occurred many times within failed 'http://0.0.0.0:80/Say.4.mp3'. Although I never see it in the success log.

Well this looks like the machine has not picked up the right IP address.  Have you verified that good old /usr/bin/GetNetworkState.sh is actually working?
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 CudaNet

  • Beta Testers
  • Hero Member
  • *****
  • Posts: 1401
  • Karma: +42/-11
  • Chimichanga !
Re: openLuup: AV plugins
« Reply #35 on: November 11, 2015, 12:46:21 pm »
Absolutely, I've even made it a point in all the documentation and a test to verify that it works.

Code: [Select]
> Execute it from the [/usr/bin] directory
$./GetNetworkState.sh
{yourIPhere}{user}@server:/usr/bin$

I was looking at the log data and I noticed this occurred many times within failed 'http://0.0.0.0:80/Say.4.mp3'. Although I never see it in the success log.

Well this looks like the machine has not picked up the right IP address.  Have you verified that good old /usr/bin/GetNetworkState.sh is actually working?
openLuup, AltUI, Zway and HomeWave, enough said...

Offline CudaNet

  • Beta Testers
  • Hero Member
  • *****
  • Posts: 1401
  • Karma: +42/-11
  • Chimichanga !
Re: openLuup: AV plugins
« Reply #36 on: November 11, 2015, 08:41:07 pm »
I think I've isolated the problem, I'll try this for a day and see how well it holds. I wrote a quick scene that logs the IP address using GetNetworkState and writing it to the openLuup log.
I test TTS and it worked just fine. I then rebooted the physical server and tested again. Sure enough no TTS. In looking at the logs, openLuup started with 0.0.0.0. I then cross referenced that data with the log data written by OpenWRT. Sure enough, the system boots so fast that openLuup/Sonos plugin never got a chance to get an IP address. The difference was around 6 seconds between openLuup starting and OpenWRT getting a lease from the DHCP  server. So I simply added a 10 second delay to the shell script.

Re-tested and it's working...

OpenWRT: Wed Nov 11 19:15:31 2015 daemon.notice netifd: lan (1335): Lease of 10.0.4.10 obtained, lease time 7200
Code: [Select]
Wed Nov 11 19:15:25 2015 auth.info sshd[1250]: Server listening on :: port 22.
Wed Nov 11 19:15:25 2015 auth.info sshd[1250]: Server listening on 0.0.0.0 port 22.
Wed Nov 11 19:15:25 2015 kern.info kernel: [   10.471577] 8021q: adding VLAN 0 to HW filter on device eth0
Wed Nov 11 19:15:25 2015 kern.info kernel: [   10.477828] device eth0 entered promiscuous mode
Wed Nov 11 19:15:25 2015 daemon.notice netifd: Interface 'lan' is enabled
Wed Nov 11 19:15:25 2015 daemon.notice netifd: Interface 'loopback' is enabled
Wed Nov 11 19:15:25 2015 daemon.notice netifd: Interface 'loopback' is setting up now
Wed Nov 11 19:15:25 2015 daemon.notice netifd: Interface 'loopback' is now up
Wed Nov 11 19:15:25 2015 kern.info kernel: [   10.483345] IPv6: ADDRCONF(NETDEV_UP): br-lan: link is not ready
Wed Nov 11 19:15:25 2015 daemon.notice netifd: Network device 'lo' link is up
Wed Nov 11 19:15:25 2015 daemon.notice netifd: Interface 'loopback' has link connectivity
Wed Nov 11 19:15:27 2015 kern.info kernel: [   13.014663] e1000e: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: None
Wed Nov 11 19:15:27 2015 kern.info kernel: [   13.022647] br-lan: port 1(eth0) entered forwarding state
Wed Nov 11 19:15:27 2015 kern.info kernel: [   13.028186] br-lan: port 1(eth0) entered forwarding state
Wed Nov 11 19:15:27 2015 daemon.notice netifd: Network device 'eth0' link is up
Wed Nov 11 19:15:27 2015 daemon.notice netifd: Bridge 'br-lan' link is up
Wed Nov 11 19:15:27 2015 daemon.notice netifd: Interface 'lan' has link connectivity
Wed Nov 11 19:15:27 2015 daemon.notice netifd: Interface 'lan' is setting up now
Wed Nov 11 19:15:27 2015 kern.info kernel: [   13.033865] IPv6: ADDRCONF(NETDEV_CHANGE): br-lan: link becomes ready
Wed Nov 11 19:15:27 2015 daemon.notice netifd: lan (1335): udhcpc (v1.23.2) started
Wed Nov 11 19:15:27 2015 daemon.notice netifd: lan (1335): Sending discover...
Wed Nov 11 19:15:29 2015 kern.info kernel: [   15.025063] br-lan: port 1(eth0) entered forwarding state
Wed Nov 11 19:15:30 2015 daemon.notice netifd: lan (1335): Sending discover...
Wed Nov 11 19:15:31 2015 daemon.notice netifd: lan (1335): Sending select for 10.0.4.10...
Wed Nov 11 19:15:31 2015 daemon.notice netifd: lan (1335): Lease of 10.0.4.10 obtained, lease time 7200
Wed Nov 11 19:15:31 2015 daemon.notice netifd: Interface 'lan' is now up

openLuup: 2015-11-11 19:15:25.530   openLuup.server:: starting HTTP server on 0.0.0.0:3480 tcp{server}: 0x231b9d8
Code: [Select]
2015-11-11 19:15:25.328   :: openLuup STARTUP ::
2015-11-11 19:15:25.328   openLuup.init::      version 2015.11.01  @akbooer
2015-11-11 19:15:25.343   openLuup.scheduler:: version 2015.11.03  @akbooer
2015-11-11 19:15:25.343   openLuup.server::    version 2015.11.01  @akbooer
2015-11-11 19:15:25.346   openLuup.plugins::   version 2015.11.06  @akbooer
2015-11-11 19:15:25.349   openLuup.scenes::    version 2015.10.26  @akbooer
2015-11-11 19:15:25.350   openLuup.chdev::     version 2015.11.01  @akbooer
2015-11-11 19:15:25.351   openLuup.io::        version 2015.10.15  @akbooer
2015-11-11 19:15:25.352   openLuup.luup::      version 2015.11.03  @akbooer
2015-11-11 19:15:25.356   openLuup.rooms::     version 2015.10.15  @akbooer
2015-11-11 19:15:25.356   openLuup.requests::  version 2015.10.30  @akbooer
2015-11-11 19:15:25.356   luup.create_device:: [1] urn:schemas-micasaverde-com:device:ZWaveNetwork:1 / no-implementation-file
2015-11-11 19:15:25.356   luup.create_device:: [2] urn:schemas-micasaverde-com:device:SceneController:1 / no-implementation-file
2015-11-11 19:15:25.357   openLuup.init:: loading configuration user_data.json
2015-11-11 19:15:25.357   openLuup.init:: loading user_data json...
2015-11-11 19:15:25.376   openLuup.init:: loading rooms...
2015-11-11 19:15:25.376   openLuup.init:: room#1 'Upstairs'
2015-11-11 19:15:25.377   openLuup.init:: room#2 'Downstairs'
2015-11-11 19:15:25.377   openLuup.init:: ...room loading completed
2015-11-11 19:15:25.377   openLuup.init:: loading devices...
2015-11-11 19:15:25.377   openLuup.init:: [1] 'ZWave', urn:schemas-micasaverde-com:device:ZWaveNetwork:1
2015-11-11 19:15:25.377   openLuup.init:: [2] '_SceneController', urn:schemas-micasaverde-com:device:SceneController:1
2015-11-11 19:15:25.377   openLuup.init:: [3] 'ALTUI', urn:schemas-upnp-org:device:altui:1
2015-11-11 19:15:25.403   openLuup.init:: [4] 'Sonos', urn:schemas-micasaverde-com:device:Sonos:1
2015-11-11 19:15:25.528   openLuup.init:: loading scenes...
2015-11-11 19:15:25.528   openLuup.init:: number of scenes = 1
2015-11-11 19:15:25.529   openLuup.init:: scene#1 'My IP Address'
2015-11-11 19:15:25.529   openLuup.init:: ...scene loading completed
2015-11-11 19:15:25.529   openLuup.init:: loading installed plugin info...
2015-11-11 19:15:25.529   openLuup.init:: ...user_data loading completed
2015-11-11 19:15:25.529   openLuup.init:: running _openLuup_STARTUP_
2015-11-11 19:15:25.529   openLuup.init:: startup completed
2015-11-11 19:15:25.530   openLuup.server:: starting HTTP server on 0.0.0.0:3480 tcp{server}: 0x231b9d8
2015-11-11 19:15:25.530   openLuup.scheduler:: starting
2015-11-11 19:15:25.530   openLuup.scheduler:3: device startup
2015-11-11 19:15:25.530   luup_log:3: ALTUI: initstatus(3) starting version: v0.96
2015-11-11 19:15:25.530   openLuup.scheduler:3: device startup completed: status=nil, msg=nil, name=nil
2015-11-11 19:15:25.531   openLuup.scheduler:4: device startup
openLuup, AltUI, Zway and HomeWave, enough said...

Offline akbooer

  • Moderator
  • Master Member
  • *****
  • Posts: 6387
  • Karma: +291/-70
  • "Less is more"
Re: openLuup: AV plugins
« Reply #37 on: November 12, 2015, 02:11:13 am »
That would seem to explain it.  I could build in a check right at the start of the openLuup init phase to see if the IP is valid, but maybe this is more of a system configuration issue?  Something for documentation, anyway!
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 CudaNet

  • Beta Testers
  • Hero Member
  • *****
  • Posts: 1401
  • Karma: +42/-11
  • Chimichanga !
Re: openLuup: AV plugins
« Reply #38 on: November 12, 2015, 08:00:37 am »
Yes, once I observed both Sonos and openLuup with their IP's set to zero's, I kind of knew. Checked it this morning and it's held. I'll add it to the install guide.

That would seem to explain it.  I could build in a check right at the start of the openLuup init phase to see if the IP is valid, but maybe this is more of a system configuration issue?  Something for documentation, anyway!
openLuup, AltUI, Zway and HomeWave, enough said...

Offline CudaNet

  • Beta Testers
  • Hero Member
  • *****
  • Posts: 1401
  • Karma: +42/-11
  • Chimichanga !
Re: openLuup: AV plugins
« Reply #39 on: November 13, 2015, 02:16:37 am »
Unfortunately the problem isn't resolved. One speaker works perfect, TTS, music etc.. I added a 2nd to see if things were still good. The answer was no.
Sequence of events:

[1] Start clean with 1 Sonos (device 4).
[2] Use Lua test to make device 4 speak. Works
[3] Run Lua to add another Sonos device. Device 5 was added.

Code: [Select]
luup.create_device ('', "IOS Push", "IOS Push", "D_IosPush.xml")       

[4] Configured device 5, discovered IP - worked, configured TTS, set for OSX.
[5] Went to devices and I can see 2 Sonos systems. Started music on device [4] - worked. Stopped. Started music on device [5] - worked. Stopped.
[6] Using same Lua test as step [2], I ran it again. No speech.

Code: [Select]
2015-11-13 01:05:03.477   openLuup.context_switch:0:  ERROR: [string "device_5"]:1413: bad argument #1 to 'find' (string expected, got nil)

[7] Remove device [5].
[8] Use Lua test to make device 4 speak. Works.

Device [4] running TTS:
Code: [Select]
2015-11-13 01:01:36.790   openLuup.server:: /data_request?id=lr_ALTUI_LuaRunHandler&command=run_lua&lua=luup.call_action(%22urn%3Amicasaverde-com%3AserviceId%3ASonos1%22%2C%20%22Say%22%2C%20%7BText%3D%22Testing%20this%20Sonos%20speaker%22%2C%20Language%3D%22en%22%2C%20Volume%3D20%7D%2C%204)&_=1447398073950 tcp{client}: 0x10f8b98
2015-11-13 01:01:36.791   luup_log:0: ALTUI: runLua(luup.call_action("urn:micasaverde-com:serviceId:Sonos1", "Say", {Text="Testing this Sonos speaker", Language="en", Volume=20}, 4))
2015-11-13 01:01:36.791   luup.call_action:0: 4.urn:micasaverde-com:serviceId:Sonos1.Say
2015-11-13 01:01:36.791   luup_log:4: Sonos: debug: Say: Testing this Sonos speaker
2015-11-13 01:01:36.791   luup_log:4: Sonos: debug: TTS queueAlert for device 4
2015-11-13 01:01:36.792   luup_log:4: Sonos: debug: TTS server (ODX): device 4 language en text Testing this Sonos speaker
2015-11-13 01:01:36.957   luup_log:4: Sonos: debug: savePlaybackContexts: device=4 uuids=RINCON_000E587EA24201400
2015-11-13 01:01:36.957   luup_log:4: Sonos: debug: controlAnotherZone targetUUID=RINCON_000E587EA24201400 sourceDevice=4
2015-11-13 01:01:36.958   luup_log:4: Sonos: debug: controlAnotherZone result=4
2015-11-13 01:01:36.958   luup_log:4: Sonos: debug: refreshNow: device=4

Add device [5]. Ran TTS for device [4].
Code: [Select]
2015-11-13 01:05:03.225   openLuup.server:: /data_request?id=lr_ALTUI_LuaRunHandler&command=run_lua&lua=luup.call_action(%22urn%3Amicasaverde-com%3AserviceId%3ASonos1%22%2C%20%22Say%22%2C%20%7BText%3D%22Testing%20this%20Sonos%20speaker%22%2C%20Language%3D%22en%22%2C%20Volume%3D20%7D%2C%204)&_=1447398073969 tcp{client}: 0x1178268
2015-11-13 01:05:03.225   luup_log:0: ALTUI: runLua(luup.call_action("urn:micasaverde-com:serviceId:Sonos1", "Say", {Text="Testing this Sonos speaker", Language="en", Volume=20}, 4))
2015-11-13 01:05:03.226   luup.call_action:0: 4.urn:micasaverde-com:serviceId:Sonos1.Say
2015-11-13 01:05:03.226   luup_log:4: Sonos: debug: Say: Testing this Sonos speaker
2015-11-13 01:05:03.477   openLuup.context_switch:0:  ERROR: [string "device_5"]:1413: bad argument #1 to 'find' (string expected, got nil)
2015-11-13 01:05:03.478   luup_log:0: ALTUI: Evaluation of lua code returned: nil
2015-11-13 01:05:03.479   openLuup.server:: request completed (8 bytes, 1 chunks, 254 ms) tcp{client}: 0x1178268
2015-11-13 01:05:05.984   luup_log:4: Sonos: debug: refreshNow: device=4

And device [5] removed. Ran TTS for device [4].
Code: [Select]
2015-11-13 01:11:53.859   openLuup.server:: /data_request?id=lr_ALTUI_LuaRunHandler&command=run_lua&lua=luup.call_action(%22urn%3Amicasaverde-com%3AserviceId%3ASonos1%22%2C%20%22Say%22%2C%20%7BText%3D%22Testing%20this%20Sonos%20speaker%22%2C%20Language%3D%22en%22%2C%20Volume%3D20%7D%2C%204)&_=1447398698232 tcp{client}: 0x26bf158
2015-11-13 01:11:53.859   luup_log:0: ALTUI: runLua(luup.call_action("urn:micasaverde-com:serviceId:Sonos1", "Say", {Text="Testing this Sonos speaker", Language="en", Volume=20}, 4))
2015-11-13 01:11:53.860   luup.call_action:0: 4.urn:micasaverde-com:serviceId:Sonos1.Say
2015-11-13 01:11:53.860   luup_log:4: Sonos: debug: Say: Testing this Sonos speaker
2015-11-13 01:11:53.860   luup_log:4: Sonos: debug: TTS queueAlert for device 4
2015-11-13 01:11:53.860   luup_log:4: Sonos: debug: TTS server (ODX): device 4 language en text Testing this Sonos speaker
2015-11-13 01:11:54.016   luup_log:4: Sonos: debug: savePlaybackContexts: device=4 uuids=RINCON_000E587EA24201400
2015-11-13 01:11:54.016   luup_log:4: Sonos: debug: controlAnotherZone targetUUID=RINCON_000E587EA24201400 sourceDevice=4
2015-11-13 01:11:54.016   luup_log:4: Sonos: debug: controlAnotherZone result=4
2015-11-13 01:11:54.016   luup_log:4: Sonos: debug: refreshNow: device=4
openLuup, AltUI, Zway and HomeWave, enough said...

Offline akbooer

  • Moderator
  • Master Member
  • *****
  • Posts: 6387
  • Karma: +291/-70
  • "Less is more"
Re: openLuup: AV plugins
« Reply #40 on: November 13, 2015, 06:08:01 am »
I've made a hot fix to the GitHub file openLuup/scheduler.lua which provides extended traceback of errors.  This should help isolating this, and any other, future problems.

Can you generate that error again and see what the log says now?
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 CudaNet

  • Beta Testers
  • Hero Member
  • *****
  • Posts: 1401
  • Karma: +42/-11
  • Chimichanga !
Re: openLuup: AV plugins
« Reply #41 on: November 13, 2015, 09:08:04 am »
Will do...

I've made a hot fix to the GitHub file openLuup/scheduler.lua which provides extended traceback of errors.  This should help isolating this, and any other, future problems.

Can you generate that error again and see what the log says now?
openLuup, AltUI, Zway and HomeWave, enough said...

Offline CudaNet

  • Beta Testers
  • Hero Member
  • *****
  • Posts: 1401
  • Karma: +42/-11
  • Chimichanga !
Re: openLuup: AV plugins
« Reply #42 on: November 13, 2015, 09:20:18 am »
Loaded file from Git, however it seems displeased.

Code: [Select]
root@Cobalt:/vera/cmh-ludl# ./openLuup_reload
lua: ./openLuup/scheduler.lua:358: attempt to index global 'schedule' (a nil value)
stack traceback:
        ./openLuup/scheduler.lua:358: in function 'socket_callbacks'
        ./openLuup/scheduler.lua:421: in function 'start'
        openLuup/init.lua:201: in main chunk
        [C]: ?
root@Cobalt:/vera/cmh-ludl#

Code: [Select]
-rw-r--r--    1 root     root          4090 Nov 13 03:05 chdev.lua
-rw-r--r--    1 root     root         22563 Nov 13 03:05 devices.lua
-rw-r--r--    1 root     root          8044 Nov 13 03:05 gateway.lua
-rw-r--r--    1 root     root          7928 Nov 13 03:05 init.lua
-rw-r--r--    1 root     root          7806 Nov 13 03:05 io.lua
-rw-r--r--    1 root     root         11000 Nov 13 03:05 json.lua
-rw-r--r--    1 root     root          9766 Nov 13 03:05 loader.lua
-rw-r--r--    1 root     root          8988 Nov 13 03:05 logs.lua
-rw-r--r--    1 root     root         22315 Nov 13 03:05 luup.lua
-rw-r--r--    1 root     root          8100 Nov 13 03:05 plugins.lua
-rw-r--r--    1 root     root         22026 Nov 13 03:05 requests.lua
-rw-r--r--    1 root     root          2964 Nov 13 03:05 rooms.lua
-rw-r--r--    1 root     root          7086 Nov 13 03:05 scenes.lua
-rw-r--r--    1 root     root         15077 Nov 13 03:05 scheduler.lua
-rw-r--r--    1 root     root         14514 Nov 13 03:05 server.lua
-rw-r--r--    1 root     root         13746 Nov 13 03:05 timers.lua
-rw-r--r--    1 root     root          5602 Nov 13 03:05 userdata.lua
-rw-r--r--    1 root     root          4079 Nov 13 03:05 xml.lua
« Last Edit: November 13, 2015, 09:27:21 am by CudaNet »
openLuup, AltUI, Zway and HomeWave, enough said...

Offline akbooer

  • Moderator
  • Master Member
  • *****
  • Posts: 6387
  • Karma: +291/-70
  • "Less is more"
Re: openLuup: AV plugins
« Reply #43 on: November 13, 2015, 11:57:58 am »
Loaded file from Git, however it seems displeased.

Shameful performance from me... there was a typo in an error branch that the unit tests can't easily exercise... but it does mean that your code was creating some sort of error!  Now we should be able to see exactly where.

It's updated in GitHib.

Sorry, as usual, for the inconvenience.
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 CudaNet

  • Beta Testers
  • Hero Member
  • *****
  • Posts: 1401
  • Karma: +42/-11
  • Chimichanga !
Re: openLuup: AV plugins
« Reply #44 on: November 13, 2015, 12:14:36 pm »
No inconvenience whatsoever. Just hoping this issue can be isolated. Will load but won't be able to test until tonight.
Thanks for your help...

Loaded file from Git, however it seems displeased.

Shameful performance from me... there was a typo in an error branch that the unit tests can't easily exercise... but it does mean that your code was creating some sort of error!  Now we should be able to see exactly where.

It's updated in GitHib.

Sorry, as usual, for the inconvenience.
openLuup, AltUI, Zway and HomeWave, enough said...