AdvantageAir Driver

[znelbok]

I am about to start the driver for the AdvantageAir system I am about to have installed.

The protocol looks pretty simple, but I want some guidance on concepts to start with so I dont get too deep and then have to back out and change direction.

There is an option for a system status message, this is a message that is sent out periodically and when a setting has changed.

The same information can also be gained from a request (from polling).

Which is the better way to go, just wait for the messages to come in (if possible), or should I poll to get the status.

Also, the zones have an option of having names given to them so that they dont have to be refered to as Zone 1, instead you can call the zone by the room name (they promote each room as a zone). The zone name can be renamed from the interface as well asbeing read. Is it possible to read these values on connection (once only read) and then assign then to a field name (eg instead of calling a field Zone1_temp, it would be called Lounge_Temp)

Mick

[robertmee]

The field construct methods take a string for the fieldname, so yes you could query the device, get the zone names, construct strings for those zone names and use them when creating the fields.

The Nuvo Concerto multizone amp does the same....It generates async status messages when someone depresses a keypad. In the Nuvo driver, we poll for the status but we also handle the asyncs. Every query/command to a zone checks the response to make sure its for that zone. If it is an async from another zone, we just process it and go back and continue looking for the zone we expect. If your unit ALWAYS sends the status in a round robin fashion for each zone (not relying on a keypad event) and it is often enough, then I wouldn't query the device for status. I would just handle the status messages that come in, and update the fields accordingly.

[Dean Roddey]

You have to poll at least once, to get the initial data. After that, it is sends all changes asynchronously, you don't have to poll to keep in sync, but you should poll once in a while to make sure the device is alive, like very minute or something. If it continuously sends info asynchronously, and you are in CML, you can just remember the time stamp of the last msg you got and in the Poll, check that you've seen something in the last X seconds. If not, then try to poll it actively so that you can go offline if it's not there anymore.

[znelbok]

Thanks guys

One thing I probably did not make clear is that the async message can be enabled/disabled, so while I understand the replies it does not clear up the issue for me

given the option which is preferred, async (which will include some polling) or polling only?

ALso, Am I wasting my time writing the driver in 1.6? Should I write it for 2.0, or are they just the same and it just needs to be compiled in 2.0

Mick

[Dean Roddey]

If the device is fast to respond, and you can get all the data you need by polling, withing spending all your time waiting for data from the device, then a purely polled scenario is simpler. You don't have to deal with async messages coming in. However, if you are doing PDL, then that's not an issue since the driver deals with that for you. If you are doing CML, then you have to deal with it, and it's far simpler to have a strictly call/response scenario.

There's no difference between 1.6 and 2.0 wrt to drivers. If it works in 1.6 it'll work in 2.0.

[rhamer]

I would generally avoid polling if possible. It is work that is done for possibly no return value.

For example you have to poll a device at a reasonably short interval so that the CQC user interface displays the change in near real time to the user. The interval depends on the device a bit, but for lighting it would want to be quite fast for the user experience to feel right. HVAC would possibly be slower.

The down side is if there is no change you are polling for no reason (remember you are just 1 of many drivers all looking for cpu time).

I would poll at startup to get the initial status, then poll infrequently to check for device disconnects and read the async messages the rest of the time. It may be a little more work, but it's a much better design.

Cheers

Rohan

[Dean Roddey]

It's technically a better design, but unless someone is very comfortable writing drivers, polling is simpler. The CPU load is infinitesimal really. The I/O is done asynchronously, so all the threads waiting for serial input are just blocked. So the benefits are of the sort that, if it's no problem for someone to write a driver that deals correctly with asyncs, then that's fine and they should. But it's better to have a reliable driver than a driver with the optimal design.

The real issue is what kind of response time the device has and how much data it provides. If you are spending all your time blocked on the serial port, then that makes outgoing commands slower because they have to wait for the serial port to be freed up.

If the device is fast to respond, and doesn't have a huge amount of data, there's not really much overhead difference, and it will be much simpler to write. The Omni Pro II is a good example. It has a huge amount of data, but it's just blazing fast to respond, so polling works very well and the driver is far simpler (and therefore stastically probably more reliable over time) than the Elk driver.

So it's a value judgement, and only experience can really say which is best. But if someone is not a code jockey, I'd argue for reliability over finesse. But workabilty has to coem before anything else and if the device just has too much data to poll at the speed it can provide it, and have reasonable latency, then you really need to use the async notifications to make up for that and use polling as an 'are you alive' ping, and to make sure that everything stays in sync over time (by slowly round robin'ing through the available data and polling it a little at a time.)

[robertmee]

While we're on the subject, should a field value be updated on a poll or async reception only, or is it okay to assume that if a write command completed successfully you can update the field based on the write. As an example, in the Maxent driver, I only have a few fields so I poll them to get real time data. The response is quick enough that I rely on this poll to actually update the field values. Should I instead, lengthen the poll cycle, and update the fields if I receive a good ACK on a write. In literal terms, take the source input as an example. Right now, I write to the TV to change the source to HDMI, and the TV responds with a confirmation. But, I don't update the field itself to HDMI until I poll for the source status. The latency between write and poll is maybe a second or two. To make it more real time to the user, should I update the field when I receive the confirmation and let the poll act as a secondary validation?

[Dean Roddey]

No, you can't update the field during a field write callback. Well, you can, but you shouldn't. CQCServer is going to update the field when you return. So you aren't waiting till the next poll to get it updated. If you return success from the field write, CQCServer will store the value that was written.

[robertmee]

No, you can't update the field during a field write callback. Well, you can, but you shouldn't. CQCServer is going to update the field when you return. So you aren't waiting till the next poll to get it updated. If you return success from the field write, CQCServer will store the value that was written.

Cool...That's the way I have it, but wanted to make sure.

[znelbok]

Well the automation interface for this system was released Yesterday and I should have an order in tormorrow.

This is going to be CML - I'm diving in to learn how to finally. I have it half written (up to the field creation), and will need lots of help to finish it off, so be prepared for lots of dumb questions as I go forward on my journey of discovery (God help you all - I hope you have the patience to put up with me) .

Mick

[znelbok]

Each zone is given a name at commissioning such as Lounge, Bedroom 1 etc.

As part of the field setup, I want to read the names of these zones and use this for the field name - Maybe something like zone_<name>.

Is this possible to do and how do I do that? I have the field creation but done based on the number of zones installed (from the manifest), but I dont know how to do the comms with CML yet.

Mick

[rhamer]

Where are the english names stored?

Can you request them from the device? if so then you can establish communications with the device, then request the names and then register your fields.

Cheers

Rohan

[znelbok]

Yes, the device has the names and that is exactly what I want to do.

Do you know of any drivers that may do this so I can look at it for inspiration?

Mick

[rhamer]

The C-Bus driver works like that, although it dosent extract english names, it extracts active group addresses instead.

So, it is an example of a driver connecting to the device extracting information and then building a field list.

It might not be the best example though, as it gets a little complex and you might get lost in the logic, but I guess the point is you decide when to report online, so you can do whatever you like beforehand to get your house in order. You don't have to add the fields at any particular point.

Cheers

Rohan

[Dean Roddey]

There probably isn't a CML one that actually extracts real names, but it's not too important. The only real issue here is that, however you extract them (and that would be specific to the protocol), you can just wait until your Connect() callback before registering your fields. As long as you have them registered and set up with good data (or put into the error state until good data is stored later) before you exit Connect() with success, you are ok.

So you just don't do any field stuff in the init. In connect you get to talking with the device, and at some point you'll ask for the names and set them up as fields and then register them, then get their values as appropriate.

If they don't strictly enforce non-duplicate names, you'll have to deal with that. You cannot register two fields with the same name or you'll get an exception when you try it.