Problem with > & < comparison in eventList2

I’m having a problem with using the > and < comparisson (the typo is intentional) in the .json file for my GoogleLatitude plugin. When incorporating one of those events for comparison in the PLEG plugin, the PLEG plugin fails during startup. The issue is most visible in the context of the PLEG plugin since the trigger/Input based on either of the two events (below) will cause the PLEG plugin to fail startup with the following log entry:

01	04/29/13 11:48:00.046	LuaInterface::CallFunction_Startup-1 device 216 function Initialize failed [string "module("L_ProgramLogicCEE", package.seeall)..."]:134: attempt to compare number with nil <0x2be03680>
01	04/29/13 11:48:00.046	LuImplementation::StartLua running startup code for 216 I_ProgramLogicEG.xml failed <0x2be03680>

And it’s obviously my code/json that has the problem as this also happens silently (trigger doesn’t work) when using the default Scene/Trigger definition/method.

But I’m at a loss for what I’m doing wrong…

I recognize the problem is that one of the variable(s) being compared is nil, which means PLEG is either comparing a variable that isn’t defined (by me) or the variable has a nil value when the data gets compared. Either way, after a few days of pulling my hair out trying to figure this out, I’m no closer to understanding where the problem lies!

My eventList2[] entries are cut/paste from the Thermostat .json with edits for the language & variables to fit what I’m using in my plugin.

You may notice the comma at the bottom of the 2nd >/< events. There’s a 3rd event. One that works fine as it’s a simple boolean comparison indicating whether the latitude device is currently within the radius specified as being "home’. ‘Home’ is defined as being inside a radius of the coordinates specified because the Latitude data collection is a bit imprecise at times.

    "eventList2": [
        {
            "id": 1,
            "label": {
                "lang_tag": "current_distance_greater",
                "text": "Distance to 'Home' is more than"
            },
            "serviceId": "urn:mark-watkins:serviceId:GoogleLatitude1",
            "norepeat": "1",
            "argumentList": [
                {
                    "id": 1,
                    "prefix": {
                        "lang_tag": "hft_distance_tag",
                        "text": "Distance:"
                    },
                    "dataType": "i4",
                    "name": "CurrentDistance",
                    "comparisson": ">",
                    "suffix": {
                        "lang_tag": "hft_meters_or_miles",
                        "text": "meters or miles"
                    },
                    "HumanFriendlyText": {
                        "lang_tag": "hft_outside_radius",
                        "text": "_DEVICE_NAME_ is located OUTSIDE a radius of _ARGUMENT_VALUE_ meter(s)/mile(s)"
                    }

                }
            ]
        },
        {
            "id": 2,
            "label": {
                "lang_tag": "current_distance_less",
                "text": "Distance to 'Home' is less than"
            },
            "serviceId": "urn:mark-watkins:serviceId:GoogleLatitude1",
            "norepeat": "1",
            "argumentList": [
                {
                    "id": 1,
                    "prefix": {
                        "lang_tag": "hft_distance_tag",
                        "text": "Distance:"
                    },
                    "dataType": "i4",
                    "name": "CurrentDistance",
                    "comparisson": "<",
                    "suffix": {
                        "lang_tag": "hft_meters_or_miles",
                        "text": "meters or miles"
                    },
                    "HumanFriendlyText": {
                        "lang_tag": "hft_inside_distance",
                        "text": "_DEVICE_NAME_ is located INSIDE a radius of _ARGUMENT_VALUE_ meter(s)/mile(s)"
                    }
                }
            ]
        },

Are you sure that you’ve got the service ID and variable name exactly matching the ones used in the implementation file? I can’t spot any problem in the .json snippet you posted, but if the device doesn’t have a value already saved under that exact service ID and variable name at startup, then [tt]luup.variable_get()[/tt] will return nil, and anything that tries to use it will of course fail.

That’s what happens when you spend ages looking at the same code and your mind fills in the missing pieces without them being present (or, why you need code reviewers!). The serviceID used for the event in eventList2 was missing “Sensor”… I.e. it should have been: GoogleLatitudeSensor1, but it was GoogleLatitude1. Argh!

Thanks for the extra set of eyes, forcing me to re-read (with the assumption that the URN was what was wrong, this time).

That’s what happens when you spend ages looking at the same code and your mind fills in the missing pieces without them being present (or, why you need code reviewers!). The serviceID used for the event in eventList2 was missing “Sensor”… I.e. it should have been: GoogleLatitudeSensor1, but it was GoogleLatitude1. Argh!

Thanks for the extra set of eyes, forcing me to re-read (with the assumption that the URN was what was wrong, this time).[/quote]

It’s amazing how we can be so blinded by our own code, after staring at it enough. That gets me all the time. Glad you’re past that one!

watou

Well I am glad that this was not a PLEG bug …
It has bothered me that you indicated you were getting PLEG errors previously …
I never thought PLEG would be diagnostic tool …

[quote=“RichardTSchaefer, post:5, topic:175202”]Well I am glad that this was not a PLEG bug …
It has bothered me that you indicated you were getting PLEG errors previously … [/quote]

With the following text, I was attempting to highlight that the fault was not that of PLEG, but my plugin. However, as is often the case, the symptoms of a bug/issue are most often apparent in a different layer of the stack than the where source of the bug is located.

[quote=“sjolshagen, post:1, topic:175202”]
And it’s obviously my code/json that has the problem as this also happens silently (trigger doesn’t work) when using the default Scene/Trigger definition/method.

But I’m at a loss for what I’m doing wrong…
[/quote]

That’s why I am very glad you found it … Even though you thought it was your problem … PLEG was reporting the problem … and it could have been my bug … and what I do not understand … bothers me !

f.y.i. When PLEG starts up … it re-evaluates all of it’s input triggers … walking the appropriate EventList2 description … and evaluating the conditions of the trigger.