Parsing Xml (and now JSN)

Hi,
I had another member show me code for working with the entire configuration and status XML file similar to what FlyBoyBob is doing. I gave it a stab today and wrote a routine that would give me the names of all the dimmers and alarm zones along with there current state. I was hoping even though I am writing in Labview that someone with more experience could look over my shoulder here and check my methods…For Example I used the Category Numbers to filter out the arrays, Cat 2’s are dimmers and cat 4’s are Alarms. I am unsure if the Categories are exclusive to these types???
I am going to switch to Jsn output tomorrow…it is harder for me to see the patterns in a Jsn file verses the Xml…next question is size…the request I am using, look at my front panel, gives back so much unwanted data and is over 10K in size…is there a different request that is more to the point? It is still working faster than reading every point individually because of the connections opening and closing so I won’t complain if thats as good as it gets!
Take a look…
Regards
Tim Alls

AllSeas Yachts

JSON will [generally] be more compact than the XML equivalent. You’re already using the lu_sdata response, which is more compact than the user_data2 (mine is ~400k) so you’re probably at about the best rates until you cutover to JSON.

See http://www.json.org/ for the pattern/parse structure of JSON output.

BTW: For compatibility, you should remove the [tt]Accept-Encoding[/tt] request header. MiOS doesn’t currently return stuff in GZIP (compressed form) but if they ever started to, it’s this HTTP-request header that indicates you can understand a [binary] GZIP (or Deflate) compressed response stream from them… so if they add compression, you’ll start getting binary data back which will break all your parsing logic.

...if they add compression, you'll start getting binary data back which will break all your parsing logic.

Hopefully an added format response feature would be in the current form:
&format=xml
&format=json
&format=gzip <— new

and nothing will break anywhere. I hope?

bob

[quote author=FlyBoyBob link=topic=6326.msg38461#msg38461 date=1303300669]

...if they add compression, you'll start getting binary data back which will break all your parsing logic.

Hopefully an added format response feature would be in the current form:
&format=xml
&format=json
&format=gzip <— new

and nothing will break anywhere. I hope?

bob

I will take it out for now…I am glad you caught it.
Is the use of categories a good way to filter the data…keeping future updates in mind?
Also, once I switch to JSN do you think grabbing this file once a second is too much for Vera? I want real time feedback on my touchscreen…it has been working perfect with SQRemote controlling the lights and my touchscreen displaying the results and that is with the XML file. It should be easier on Vera in the JSN format.
Thanks for the input!
Regards
Tim Alls
AllSeas Yachts

is there a different request that is more to the point?

Yes, there is: create a new request. :slight_smile:

All you need is [tt]http://wiki.micasaverde.com/index.php/Luup_Lua_extensions#function:_register_handler[/tt] and some Lua/Luup code that returns the data you are interested in.

Is the use of categories a good way to filter the data....keeping future updates in mind?

AFAIK, the device categories as defined at [tt]http://wiki.micasaverde.com/index.php/Luup_UPNP_Files[/tt] are the only way to get reliable information about the type of a device (my LOUIS4Vera plugin is based on device categories).

Ap15e,
That is very interesting…looks like you have forced me into “Luaa Coding” which so far I have been steering clear of it!
Good to hear about Categories…that makes my job easier!
I have been studying the SQRemote and the way it communicates with the Vera and I am considering programming my touchscreen to duplicate the MIOS format and give the information to it that I want to display. It might be an easier way to present all the information I want without having to go through The Vera. In other words the touchscreen would appear as a MIOS unit. It is easy to extract data from Vera but more difficult to get information inside it. I feel like I am trying to write programs with my monitor switched off when I deal with the Vera…I don’t know how all of you do it! I guess I am getting old and inpatient…
Regards
Tim Alls
AllSeas Yachts

[quote=“FlyBoyBob, post:3, topic:168168”]

…if they add compression, you’ll start getting binary data back which will break all your parsing logic.

Hopefully an added format response feature would be in the current form:
&format=xml
&format=json
&format=gzip <— new

and nothing will break anywhere. I hope?

bob[/quote]
If added, it’s done at the [HTTP] transport layer, not the Application layer, so there’s no need for a new format. It’s the same format, just a different encoding, and the W3C spec indicates that a User Agent indicates it “can accept” the encoding using the [tt]Accept-Encoding[/tt] header values, and the Server Entity response will include the [tt]Content-Encoding[/tt] header if it has been encoded (Compressed, in this case)

In most cases, this is all handled by the underlying HTTP lib that folks use, but since Tim’s dealing with the raw streams he has to set the right bits.

The compression, if added, would be done outside of the MiIOS code, as configuration in the lighty that it runs.

Bottom line, if someone’s code cannot understand Compression, it should avoid advertising that header. (to be spec compliant, and to avoid surprises down the road)

Thankyou…
That’s why I wanted more eyes on my code!
My rebelious days are over…I just want to comply. :slight_smile: ;D
Regards
Tim

I finished the JSN Parsing program and it works great. I was disappointed that the Scenes are not given a Cat #…now I have to add extra code to extract them. I need a couple more of your great ideas in the way I implement this program…
I am using it to update all the variables on my touchscreen interface that I posted previously…I don’t want to overload Vera with needless request…The JSN format really cut down on the data exchange so it was worth the effort for sure.
Would you have the program go into a dormant stage when noting is going on, say update every 30 seconds and when it sees a change come to life and update once a second?
Any Ideas?
Thanks for the INPUT!
Regards
Tim Alls

AllSEas Yachts

There is a way where you can call these URLs and block until a data change event occurs (or a caller specified timeout).

This is how the regular remotes do it so the don’t have to rapidly poll.

If memory serves correctly, the first call returns a key that you have to pass on the next call (and so on). You should be able to see this if you have wireshark attached at the right part of your network and watch what one of the other remotes does.

Guessed,
Thanks for the suggestion.
I was also wondering if would be hard to have Vera send out a notice that something had changed using a little Luua code??
ap15e,
Where would you place the code for a custom request? Sorry, I am new to Luaa coding!
Regards
Tim

I was also wondering if would be hard to have Vera send out a notice that something had changed using a little Luua code??
It's possible, as it's only [Lua] code, but it's not going to be the simplest [i]road-most-travelled[/i] solution. There are all sorts of "listener" mechanisms in Luup that you can use to subscribe to specific change events and do whatever you want with them.

It’ll also only work in situations where there’s something else, on the same network, listening for the requests that Vera will “throw” at it. The other mechanism can work, for example, over the [tt]cp.mios.com[/tt] infrastructure.

That said, if you’re only doing this to reduce the traffic volume then it’s probably not really worth the effort. Most modern Wired (and even Wireless, but not 3G) Networks can handle a bunch of traffic without any measureable pain… at levels way above what Vera [generally] produces.

I never get the spelling right…Luup! :slight_smile: I told you I was new to it…ha
Maybe its not worth the effort…
OK, well I will give it a try at once a second and see what the Little Bugger does!
When I ran it for a test (ten minutes) it never gave me a problem. Now that I am in Jsn format it might not take much. I bet that SQRemote polls at once a second and that never gives any issues and they are using the XML format1
Regards
Tim

[quote=“TimAlls, post:13, topic:168168”]I bet that SQRemote polls at once a second and that never gives any issues and they are using the XML format1
Regards
Tim[/quote]
I’ll take that bet, on both items, how much do you want to lay down? :wink:

Wireshark is your friend here, in order to see what they’re actually doing…

I was also wondering if would be hard to have Vera send out a notice that something had changed using a little Luua code??

You could use http://wiki.micasaverde.com/index.php/Luup_Lua_extensions#function:_variable_watch to ‘watch’ a variable.

ap15e, Where would you place the code for a custom request? Sorry, I am new to Luaa coding!

In a simple Luup plugin or via ‘MiOS developers’ → ‘Edit Startup Lua’.

@Guessed,
I don’t think betting with you would pay off! Maybe on a boatbuilding question…ha

From Square Connect:
http://xxx.xxx.xxx.xxx:49451/data_request?id=user_data2 Where the xxxs represent the ip address of your Vera unit.

This URL will provide us with a JSON document that describes the devices and services provided by your Vera unit.

The above URL is called only once, at SQ Remote startup. After that, we poll the Vera unit at the following URL:

http://192.168.1.11:49451/data_request?id=lu_status2&DataVersion=1

The DataVersion changes when your Vera unit tells us there is a new version, so it increments over time. This is a JSON document also that tells us about changes between “data versions” of the Vera unit. I don’t think that the Vera unit informs us when a new device is added so this is why I think a restart is required.

End Quote

You won on the first point! I don’t know about the polling…I just know that mine updates the door sensors within a second. I will check it with wireShark…like you said, and maybe I will learn something!

@ap15e,

I will look at your idea and check it out!
Thanks,
Tim

This will help with what they’re doing also, although the data supplier URL is a little different from what they call:

http://wiki.micasaverde.com/index.php/UI_Simple#lu_sdata:_The_polling_loop

Note that subsequent URL calls block, for a client-specified timeout period, before returning content. If any change occurs in the data structure in MiOS during this time, they’ll unblock and return the [changed] data immediately.

That’s why it feels like the Control Points are polling frequently… they’re not, unless lots of changes are going on to your data in Vera (lights-on, lights-off, and a rapid succession between the two :wink:

Otherwise they sit there waiting for the HTTP Request to return something… and most of the time there aren’t changes going on in the system so they’re doing “nothing”… This is a fairly standard Browser-based JSON coding technique also.

@guessed,
I am sure you know what your talking about and Thanks for the feedback. I will check it out and see if I can do the same! This has been like going back to school for me…arggg
Where did you learn all this any how?!
On another subject…how can I access the LEDs on the Leviton four button controllers?
Tim

A miss-spent youth, extending into a miss-spent adulthood 8)

On another subject....how can I access the LEDs on the Leviton four button controllers?
This might give you some ideas... http://wiki.micasaverde.com/index.php/Leviton_LED_Debugging

Perfect…
http://192.168.2.117:3480/data_request?id=lu_action&DeviceNum=24&serviceId=urn:micasaverde-com:serviceId:SceneControllerLED1&action=SetLight&newValue=1&Indicator=2
I can easily manage with this little goodie…now I have to figure out how I want it to function! I think to start with I will have the LEDs follow the light intensity. (I am just working on Zone Controllers right now)
Thanks
Tim