A few tweaks:
a) eliminate use of [tt]loadstring(…)[/tt], to avoid potential “abuse” of the overall syntax.
Effectively [tt]loadstring[/tt] is akin to the things that are used to cause XSS and SQL injection attacks so I’ve changed these to a more explicit [tt]luup.*[/tt] request to avoid the injection possibilities.
This code is not yet tested, but it should function correctly with a little tweaking. Note that the [tt]pcall[/tt] hooks need to be added back in.
b) Dual-code to handle “testing” the output completely outside of Vera
I have [crude] wrapper method implementations that let me run the codebase outside of Vera, for functional/syntax testing, as well as inside Vera for functional/integration testing. It’s important to keep this code fairly Luup-neutral so that tests can be added without having to embed it into Vera. There are now separate stub-functions for both Luup and pure implementations.
c) Addition of array-like syntax for Devices.
eg. you can now reference devices as [tt]device[82].name[/tt], as well as [tt]device.name[/tt]. The latter requires the deviceId parameter to be passed, and will most likely be the common [re-usable] snippet syntax in Scenes (etc). The former allows for referencing arbitrary devices.
Future versions of this syntax can be expanded to permit a named-device syntax like [tt]device[“Kitchen Light”].name[/tt] if we’re interested (*)… with associated problems…
This should only be considered a working prototype, one that helps us understand if this is the syntax we really want, or if we want another. We still need to really have that discussion, which was the intent of this thread. I’ve worked this prototype as a means to ensure that any proposal also has a vetted/trial implementation so people can see what it really looks like.
The following examples are now understood by this code. They all take the general form:
{value}
{value,dataType}
{value,dataType,formatString}
where
[ul][li]value - a string of the form [tt]system.[/tt], [tt]device.[/tt], [tt]device[deviceId].*[/tt][/li]
[li]dataType - a datatype of either [tt]String[/tt], [tt]Number[/tt] or [tt]Date[/tt]. The default, if not specified, is [tt]String[/tt][/li]
[li]formatString - a datatype-specific format identifier used for layout/formatting of the output[/li][/ul]
Values...
{system.latitude}
{system.la4-titude}
{system.timezone}
{system.city}
{device.name}
{device[82].name}
{device.ip}
{device[82].ip}
{device.mac}
{device[82].mac}
{device.parent.name}
{device[82].parent.name}
{device.service[urn:micasaverde-com:serviceId:SecuritySensor1].LastTrip}
{device[82].service[urn:micasaverde-com:serviceId:SecuritySensor1].LastTrip}
{device.service[].LastTrip}
{device[82].service[].LastTrip}
{device.room.name}
{device[82].room.name}
{device.parent.room.name}
{device[82].parent.room.name}
Formatting...
Number values we dont understand {5.5}, {5.5,Number}, {5.5,Number,%10.4f}
Number values we understand {pi}, {pi,Number}, {pi,Number,%10.3f}
String values we dont understand {title}
Dates we understand {currentTime}, {currentTime,Date}, {currentTime,Date,%x}, {currentTime,Date,%H:%M}, {currentTime,Date,"%d.%m.%Y"}
Luup is not defined
Values...
luup.latitude
INVALID
luup.timezone
luup.city
luup.attr_get("name",57)
luup.attr_get("name",82)
luup.attr_get("ip",57)
luup.attr_get("ip",82)
luup.attr_get("mac",57)
luup.attr_get("mac",82)
luup.attr_get("name",luup.devices[57].parent_num)
luup.attr_get("name",luup.devices[82].parent_num)
luup.variable_get("urn:micasaverde-com:serviceId:SecuritySensor1","LastTrip",57)
luup.variable_get("urn:micasaverde-com:serviceId:SecuritySensor1","LastTrip",82)
INVALID
INVALID
luup.rooms[luup.devices[57].room_num]
luup.rooms[luup.devices[82].room_num]
luup.rooms[luup.devices[luup.devices[57].parent_num].room_num]
luup.rooms[luup.devices[luup.devices[82].parent_num].room_num]
Formatting...
Number values we dont understand {5.5}, {5.5,Number}, {5.5,Number,%10.4f}
Number values we understand 3.141592654, 3.141592654, 3.142
String values we dont understand {title}
Dates we understand 1346041025, Sun Aug 26 21:17:05 2012, 08/26/12, 21:17, "26.08.2012"
)