Page 1 of 2

[userModule] XMLDevice

Posted: 04 Apr 2015 21:17
by pz1
Last version: 1.0.3 (2016-07-09)
Tested with: v2.2.4-rc2
STATUS: Stable
Download: Online Appstore

userModule XMLDevice


XMLDevice has been developed in response to the existing httpDevice. Both do create "normalised" virtual devices that are compatible with the Z-Way Home Automation system.
This module has been derived from the OpenWeather module. It is meant to turn a single XML element into a virtual device. In the configuration screen the user has to specify a number of parameters that defines the virtual device. It is important to adhere as close as possible to standard terminology as defined in the scales.xml file from Z-Way.
XMLDevice.PNG
XMLDevice.PNG (22.39 KiB) Viewed 27961 times
For the time being sources are only kept on Github.

Re: [userModule] XMLDevice

Posted: 11 Apr 2015 13:00
by pz1
I would like to extend this module with an automatic selection of a metric-type icon to be displayed on the Home Automation screen.
  • What is the path to the icon folder used with the automatically generated virtual devices?
  • How to deal with user supplied icons?

Re: [userModule] XMLDevice

Posted: 29 Jun 2015 15:15
by pz1
A few days ago, I did encounter a problem with this module. The values assigned to this virtual device, probably is of type:string. I found out because the userModule Arithmetic could not deal with the value. That worked after I added parseFloat to the code (not yet on github)

So I guess the module should at least have the options to deliver the retrieved XML element as:
type:float
type:int
type:text


Unfortunately the Z-Way API does not list a DeviceType in which I can store text. Float and Int types can quite well fit in sensorMultilevel, but text is appropriate.

How do I solve this? Can I use DeviceType text, just as in the new InfoWidget module? Is DeviceType:text now formally part of your apiary.io, and recognised by the HA engine?

17:00 Updated last two lines

Re: [userModule] XMLDevice

Posted: 30 Jun 2015 02:10
by PoltoS
It would be good to add a checkbox in options to select between numeric (float/int) and text values and change deviceType accordingly. text like in InfoWidget is perfect.

Re: [userModule] XMLDevice

Posted: 30 Jun 2015 10:09
by pz1
Thanks, this helps to simplify it for the user side.

Re: [userModule] XMLDevice

Posted: 30 Jun 2015 18:43
by pz1
There is a new release on Github (see link in first post) that uses PoltoS' suggestion.

Worked for me as text and numerical nodes. The later both with float/integer conversions.

Re: [userModule] XMLDevice

Posted: 01 Jul 2015 04:20
by PoltoS
I've also updated CodeDevice and HTTPDevice recently on github. I think you might want to add these new features to your module too.

https://github.com/Z-Wave-Me/home-autom ... 51123d228f

Re: [userModule] XMLDevice

Posted: 01 Jul 2015 10:02
by pz1
PoltoS wrote:I've also updated CodeDevice and HTTPDevice recently on github. I think you might want to add these new features to your module too.
It crossed my mind yesterday while perusing the changes on github.

The starting point of XMLDevice was in the OpenWeather module, from which I derived this generalisation for a single XML sensor module. Actually a a slow module for not to rapidly changing data. As a result, as it is now, the minimum polling interval is one minute.

If you think a device like this is something that should be part of your core collection of modules, please feel free to take it further. Almost all IP comes from you anyhow :mrgreen: .
Though I have learned a little bit of JS recently, I say it again, I am not a programmer! Making this in something comparable to the http device is well beyond my league and ambitions.

Re: [userModule] XMLDevice

Posted: 02 Jul 2015 20:07
by PoltoS
We will try to review it once we are ready with our modules "shop"

Re: [userModule] XMLDevice

Posted: 02 Jul 2015 20:14
by pz1
PoltoS wrote:We will try to review it once we are ready with our modules "shop"
If you do want your own XML Device, don't try to fix mine, but throw it away, and do it properly based on the idea/functionality of the present module