"Delivery failed" message

I’m getting Delivery failed message when I’m trying to use controls of any “hand made” Luup device.
It isn’t reflected in the log at all - if I click on On/Off, or Left/Right button not a single line get added in the log.

IS there any way to see what’s the cause of this error?

How are you sending the messages? Within Luup, or on the lu_action URL, or in the UI?

From UI - just click on the buttons of the device

I don’t necessarily expect it to work - but I think we should see some hints of failure reasons in the log

Can you: a) turn on verbose logging, b) tail the logs grep ‘^08’ which will show you all the incoming actions, c) submit a trouble ticket letting me know the exact time of the action in question? It has to state in the logs why the action failed. I can look in your logs and explain what it means.

Done. grep ‘^08’ shows nothing when I click on UI controls of my devices

Submitted ticket: 855, access is open

325xi. I’m sorry, but the trouble ticket doesn’t include the Luup plugins you wrote (just the logs), and the trouble ticket didn’t mention the access code for your system (it’s the 6 digits following your serial number). Without that I couldn’t login. I just released firmware 789 which updates the trouble ticket so now any trouble tickets will include your Lua, UPNP and Luup plugins files. You can upgrade and do another trouble ticket, or email me the remote access code, or email me your xml & lua files for me to test it locally.

Just tried again with the new FW. Delete works now - thanks.

Still getting Delivery failed…

Successfully submited ticket: 860

I found the problem. There are 2 things, actually.

You created a parent device which is a ‘camera controller’, like a DVR, that has multiple cameras within it. The parent device has an implementation file I_ICamView.xml, and the children, the cameras have one too: I_iCamViewPTZ.xml

In the implementation file for the parent device which manages the cameras you didn’t specify the UPNP device file for the children. This is how the line should read:

lu_chdev_append(lul_device,child_devices,1,"Camera #1","urn:schemas-upnp-org:device:DigitalSecurityCamera:1","D_DigitalSecurityCamera1.xml","I_iCamViewPTZ.xml","urn:micasaverde-com:serviceId:Camera1,URL=pda.cgi?page=image&cam=1",true)

Without the “D_DigitalSecurityCamera1.xml”, the devices were created, but without any UPNP definition. Because incoming actions come in via UPNP, every device has to have a valid UPNP device file and service or it won’t be able to receive actions.

The second is that in the parent device’s UPNP device file you have this:

<handleChildren>1</handleChildren>

I included that in my examples because in mine I put the actions for the children within the parent’s implementation file. So I wanted all actions to a child device to go through the parent’s implementation file. In your case, that’s not happening. The parent implementation, which is the ‘dvr’ device that manages the cameras, specifies one implementation file: I_ICamView.xml. That implementation file has no pan/tilt/zoom action handling. The cameras, the child devices, have their own implementation file, I_iCamViewPTZ.xml. But because of that ‘handlechildren’ flag, the actions are passed off to the parent’s implementation.

So you have 3 options:

  1. remove the handlechildren flag.

  2. Add I_iCamViewPTZ.xml to the D_ICamView.xml device spec so that the parent has the implementation, like this:

    I_ICamView.xml I_iCamViewPTZ.xml
  1. The third option, which is my personal taste, is to just get rid of I_iCamViewPTZ.xml and put the lua script for PTZ inside I_ICamView.xml and leave the handleChildren flag. The advantage of this is just that you have everything related to the iCamView in only 1 implementation file, and since there’s not a lot of code (just some PTZ functions) I figure it’s not necessary to break it into multiple files. CAVEAT is that I’m assuming every camera will implement PTZ the same way with the same code. If that’s not the case, if the iCamView has different types of cameras which do PTZ differently, then you should do option #1 like you intended because with option #2 or #3, any incoming action “MoveRight” to either type of camera will go to a single “MoveRight” action handler within the parent device. You’d need to put an ‘if’ block in the MoveRight to see which type of camera it is and handle it appropriately. In that case, it would probably would be cleaner to have separate implementation files for each method of PTZ implementation, and in the ch_dev_append loop, just specify the correct one for each type of camera.

If you delete the iCamView device in your Luup UI, then fix those 2 issues, and then re-add it, then all is fine. The reason you have to delete and re-add it is because with the 790 release, if you previously specified with ch_dev_append the same device type, but without a device file, and now you add the device file, it doesn’t realize it needs to update teh device. I just committed a fix for this, but in the meantime, just delete and re-add the device after you fix the issue.

Great - it works now - I really appreciate your help.

Couple of questions though:

  • absence of device file seems to be the cause of the error message - is it possible to add some logging to ensure this kind of error will be traceable?

  • I tried to replace with ( normally response time of the server is very good), but with I started to get another message: “Undefined:”, the action worked though - again I couldn’t find anything in the log that would hint on the message cause.

  • is there easy way to add more buttons on UI for extended functionality?

  • in “Full Size” view the minimal refresh time is 5s. Is it possible to reduce it?

absence of device file seems to be the cause of the error message - is it possible to add some logging to ensure this kind of error will be traceable?

Done. There’s now a warning (log level 2): Device_LuaUPnP::LoadDeviceDoc no device doc for x

I tried to replace with ( normally response time of the server is very good), but with I started to get another message: "Undefined:", the action worked though - again I couldn't find anything in the log that would hint on the message cause.

I can reproduce the problem. Unfortunately it’s in the javascript on the web ui, and our javascript programmer just left today for a 2 week vacation. You can ignore the dialog box, the command is working. I’ll ask him to fix it when he’s back.

is there easy way to add more buttons on UI for extended functionality?

We’ve been trying to think of a good way to address this. One thought that came to mind was being able to put a URL in the device specification for “setup” and “control”, which would be something you register a handler for. The “setup” would be for the devices page, the “control” for the dashboard. The problem there is that whatever you do would be specific for our existing Vera UI, and if, for example, someone had an iPhone app, the control wouldn’t work because it’s non-html. But there’s not an easy universal way to describe a widget. So we’re still debating how to address this.

in "Full Size" view the minimal refresh time is 5s. Is it possible to reduce it?

That’s a java script question. I’m sure there is, but I don’t know it. Going back to the prior question, a way to embed live video is very high on our priority list. The challenge we’ve got is that many of the cameras don’t use a standard browser-compliant way of providing live video. They instead require an active-X control that only works in IE on Windows. What about your cameras? Any ideas?

[quote=“micasaverde, post:10, topic:164609”]

is there easy way to add more buttons on UI for extended functionality?

We’ve been trying to think of a good way to address this. One thought that came to mind was being able to put a URL in the device specification for “setup” and “control”, which would be something you register a handler for. The “setup” would be for the devices page, the “control” for the dashboard. The problem there is that whatever you do would be specific for our existing Vera UI, and if, for example, someone had an iPhone app, the control wouldn’t work because it’s non-html. But there’s not an easy universal way to describe a widget. So we’re still debating how to address this.[/quote]

IMHO, you could think of providing both ways: the hard way, and the easy way. What you’re talking about is full complete solution, the “hard” way - my guess it’s could take a time.
But there’s a simple way that would most likely satisfy average needs. Add a new XML tag to describe basic custom controls: a button, check box, radio box, may be slider, etc. All user should be able to do is to provide name, mouse hover text, min/max values if relevant, and action name. All the rest is controlled by the engine - look-n-feel, location, etc. And you provide user with a function to retrieve the selected value and/or just trigger the action. This is easy to implement, it won’t break your UI, and it will give the required degree of flexibility to the developers.

[quote=“micasaverde, post:10, topic:164609”]

in “Full Size” view the minimal refresh time is 5s. Is it possible to reduce it?

That’s a java script question. I’m sure there is, but I don’t know it. Going back to the prior question, a way to embed live video is very high on our priority list. The challenge we’ve got is that many of the cameras don’t use a standard browser-compliant way of providing live video. They instead require an active-X control that only works in IE on Windows. What about your cameras? Any ideas?[/quote]

iCamView is not an exception, but at least it provides both ActiveX and Java applet options. The latter could possibly be embed on the UI.

325xi… I hear you about the XML tag to describe button, check box, radio box, etc. But, if we create our own parsing/markup language with our own tokens for that, like:

I want to control <drop-down choices=“blinds”, “lights”> whenever it is …

Well in that case essentially we’ve duplicated HTML, and while maybe it could be a bit more optimized, I think that since so many people know HTML we’d be better of to just embed HTML widgets instead of creating our own markup language to do the same thing. But, you do really need to have some sort of javascript capabilities. For example, look at the configuration widget for cameras. It says things like:

Turn on the following lights:
[ ] light #1
[ ] light #2
etc.

and these sensors:
[ ] sensor #1
etc.

That’s more than just a markup, you need to be able to iterate the list of devices, filter out the lights and sensors, and build check boxes. Then you need to be able to compose them into the configuration data. For example, with the cameras we save the list of lights to turn as a comma delimited text string. But that means that a java script function needs to evaluate which lights are checked and concatenate the device id’s into a string. So what I want to do is have the same thing for the html widgets as for the Lua, where we have shared functions in the java script to read device config, set variables, call actions, etc. I think we can still keep it simple. But I need to work with our javascript dev, and he’s on vacation right now till 3 Aug.

Is the below still true? I am trying to create child devices that use their own implementation files. Anytime I do this though, I hang on “Running Lua Startup.” If I load the same implementation file to a parent device, it works fine. I’ve tried removing the handlechildren tag, and still no go.

[quote=“micasaverde, post:8, topic:164609”]So you have 3 options:

  1. remove the handlechildren flag.

  2. Add I_iCamViewPTZ.xml to the D_ICamView.xml device spec so that the parent has the implementation, like this:

    I_ICamView.xml I_iCamViewPTZ.xml
  1. The third option, which is my personal taste, is to just get rid of I_iCamViewPTZ.xml and put the lua script for PTZ inside I_ICamView.xml and leave the handleChildren flag. The advantage of this is just that you have everything related to the iCamView in only 1 implementation file, and since there’s not a lot of code (just some PTZ functions) I figure it’s not necessary to break it into multiple files. CAVEAT is that I’m assuming every camera will implement PTZ the same way with the same code. If that’s not the case, if the iCamView has different types of cameras which do PTZ differently, then you should do option #1 like you intended because with option #2 or #3, any incoming action “MoveRight” to either type of camera will go to a single “MoveRight” action handler within the parent device. You’d need to put an ‘if’ block in the MoveRight to see which type of camera it is and handle it appropriately. In that case, it would probably would be cleaner to have separate implementation files for each method of PTZ implementation, and in the ch_dev_append loop, just specify the correct one for each type of camera.[/quote]

I guess it (roughly) is. Can you share some logfiles?

It’s funny… the other day i was getting a missing fileset error in the log for the child devices’ imp file. Now, I am not getting that error, but still hanging on lua startup. I couldn’t find the relevent portion of the log file, so I attached the whole thing. It’s not pretty since I have other issues related to this plugin that I haven’t sorted out yet - service related. Anyway, the parent device is device #64 (ActiveRFID) and I have 2 child devices (RFIDTransmitter) at 65 and 66.
Thanks Javier…

Javier, I moved all my imp code to the parent imp file until this gets figured out. One thing that I noticed is after doing so, I no longer get the error that the serial port is already in use by device #64. I’m wondering if the child imp file is causing multiple connection attempts to the serial device.

sounds interesting. hard to tell for sure without seeing your code, of course.

i read your logfile; but couldn’t see where it was hanging. it might be easier to do it ‘live’. can you enable the tech support access so i can play with it?