Digging into Lighting plugin

[bulek]

Hi,

following Climate plugin, here's a thread about lighting plugin.

I've started basic wiki page here :

http://wiki.linuxmce.org/index.php/Lighting_Plugin

I currently spot few possibilities for enhancements that I plan to do, but would like to have some discussion on this matter first:

1. it seems that group of commands that will be displayed on Orbiter's floorplans is determined by floorplan object type and not by type of device (usually determined by Template or Category). In consequence, dimmable controls are displayed on floorplans regardless being a light dimmable device or light on/off device by template. There are at least two ways out of this, but I'm not sure what is the right thing to do to solve this...

2. it seems that gray color is not used for dimmed lights

3. discussion: it seems that we have only light switches and not correct LIGHT devices (distinction is that switch goes to new state regardles of actual state). In my experience those switch devices can be also used as normal devices (by sending proper state events, so they will act accordingly to real state), but somewhere in the future we will have to find a clean solution to this matter...

Thanks in advance,

regards,

bulek.

[hari]

3. discussion: it seems that we have only light switches and not correct LIGHT devices (distinction is that switch goes to new state regardles of actual state). In my experience those switch devices can be also used as normal devices (by sending proper state events, so they will act accordingly to real state), but somewhere in the future we will have to find a clean solution to this matter...

i don't understand that.

br, Hari

[bulek]

3. discussion: it seems that we have only light switches and not correct LIGHT devices (distinction is that switch goes to new state regardles of actual state). In my experience those switch devices can be also used as normal devices (by sending proper state events, so they will act accordingly to real state), but somewhere in the future we will have to find a clean solution to this matter...

i don't understand that.

br, Hari

Some time ago I contacted Pluto about this... The problem is that switch light device goes to new state without doing anything... So when you click to ON, it will go yellow after few seconds, without anything else... I talked to Pluto guys and they said that this behaviour is normal, cause those devices are switches and not lights...

what I envision as proper light device :
- you click ON on floorplan
- it goes to your automation driver and down to the automation level
- then it comes back to automation driver as change and then back to floorplan as event that light has changed
- now the light turns yellow

Currently the light switches on by itself, although it still works if you send proper event afterward (being off or on from automation layer)... But if your automation layer dies, you get wrong impression that light is on...

HTH,

regards,

Bulek.

[hari]

Bulek,

i've read that again and again, discussed it with tschak, but still are unable to understand it. I tried with a relay plug (Light Switch (on/off) #37). I press 100%, it goes on, same for the floorplan symbol (lit yellow). I press off, it goes off, floorplan symbol becomes black.

br, Hari

[hari]

or do you talk about having the wrong state on the floorplan resulting in the buttons having no effect? That only affects GSD, because of the AVMessageTranslation. Btw, the Z-wave driver does polling and sends proper state changed events (implemented by jondecker in the lighting plugin early this year). After startup e.g. after a quick reload, it does a broadcast report request, fetches all states and updates lmce. So you should always have correct states on the floorplan, even after a reload. But again, pressing on/off always results in the action and does not depend on the floorplan state (for non-GSD).

br, Hari

[bulek]

Bulek,

i've read that again and again, discussed it with tschak, but still are unable to understand it. I tried with a relay plug (Light Switch (on/off) #37). I press 100%, it goes on, same for the floorplan symbol (lit yellow). I press off, it goes off, floorplan symbol becomes black.

br, Hari

hmm, how to explain. it's about two way communication with automation system. for instance your automation driver fails. you click on light switch and still get from black to yellow state although this won't happen on actual light device....

now if we had real light device, device would never go from black to yellow cause it won't receive proper response (event) from automation driver...

Yes I agree, currently it works, if your automation is working, cause switch goes to yellow and then you send proper event again from automation level anyway, so this doesn't matter, as long as your automation is working...

I talked this (maybe it was Eugene) with pluto guys. The reason for using switch devices instead of light devices was cause at that time there were only a few two way automation systems.... And such behaviour is ok for a switch - cause when you press it, it changes its state, but that doesn't mean that the light is on...

What I think is that light device shouldn't go yellow without feedback from automation system...

I hope we won't get lost in a tree - I'd like to discuss about forest... for now this tree is not so important, but eventually this will have to be solved... For two way automation systems maybe we will have separate set of light devices that will not act as switch...

Maybe we better discuss this on Chat, but link doesn't work anymore. Where can I find you ?

thanks in advance,

regards,

Bulek.

[darrenmason]

1. it seems that group of commands that will be displayed on Orbiter's floorplans is determined by floorplan object type and not by type of device (usually determined by Template or Category). In consequence, dimmable controls are displayed on floorplans regardless being a light dimmable device or light on/off device by template. There are at least two ways out of this, but I'm not sure what is the right thing to do to solve this...

It sort of needs to take both into account...
It just needs some more logic in the method. It is currently returning the dimmable group lighting object for all its known lighting floorplan objects and the on/off for anything else. I would have thought it needs to return either of those two group controls depending upon both whether it is a known lighting object AND then if it is dimmable or not. The default behaviour in this case is almost like an unhandled case and should return something generic (non lighting).

Determining if it is dimmable would be preferably done from device data rather than the type of template. I don't think it is correct for the lighting plugin to know all the possible lighting device types - it is fair for it to expect to alter behaviour based on device data (of which floorplan object is anyway).

So if I have understood your requirement correctly - I think the best solution is to add "dimmable" as device data to the devices in use and modify the plugin code to check that as well as what it is doing now. Your other alternative would be to have another 'dimmable' floorplan object for each of the ones that there is now which is far more painful.

Anyway, just some thoughts

Darren

[bulek]

1. it seems that group of commands that will be displayed on Orbiter's floorplans is determined by floorplan object type and not by type of device (usually determined by Template or Category). In consequence, dimmable controls are displayed on floorplans regardless being a light dimmable device or light on/off device by template. There are at least two ways out of this, but I'm not sure what is the right thing to do to solve this...

It sort of needs to take both into account...
It just needs some more logic in the method. It is currently returning the dimmable group lighting object for all its known lighting floorplan objects and the on/off for anything else. I would have thought it needs to return either of those two group controls depending upon both whether it is a known lighting object AND then if it is dimmable or not. The default behaviour in this case is almost like an unhandled case and should return something generic (non lighting).

Determining if it is dimmable would be preferably done from device data rather than the type of template. I don't think it is correct for the lighting plugin to know all the possible lighting device types - it is fair for it to expect to alter behaviour based on device data (of which floorplan object is anyway).

So if I have understood your requirement correctly - I think the best solution is to add "dimmable" as device data to the devices in use and modify the plugin code to check that as well as what it is doing now. Your other alternative would be to have another 'dimmable' floorplan object for each of the ones that there is now which is far more painful.

Anyway, just some thoughts

Darren

I'm asking my self (and developers) quite similar question. I think we have to consider that more and more devices will be automatically recognized - and there the easiest way is to define one or another device and that's it. Since lights don't differ much, in this case, distinction based on template or subcategory is quite enough...

I'd kindly ask if developers with more insight try to discuss this....

Thanks in advance,

regards,

bulek.

[darrenmason]

My point was that I don't think that plugin code should perform logic based on devices that could exist as this is the most variable aspect of the system.
I am trying to avoid the need to change code to suite new devices.

SubCategory is better as it allows devices to inherit know behaviour based on being assigned to the category.

I think using device data adds a bit more flexibility as it allows behaviour/logic to be coded based on data rather than types.

In this instance, it is debatable what should be used as the dimmable property of a device does not change over time - so you are not likely to need the flexibility to change. Therefore using subcategory will acomplish what is needed.

I am interested in what some of the other developers think as I have seen some code which is written with logic based on device type (templates) where I would have thought it would have been better to use different patterns.

It might be better to code up your options and post the code fragments (or pseudocode) to get other developers to comment if you are still stuck for a design decision....

[bulek]

My point was that I don't think that plugin code should perform logic based on devices that could exist as this is the most variable aspect of the system.
I am trying to avoid the need to change code to suite new devices.

SubCategory is better as it allows devices to inherit know behaviour based on being assigned to the category.

I think using device data adds a bit more flexibility as it allows behaviour/logic to be coded based on data rather than types.

In this instance, it is debatable what should be used as the dimmable property of a device does not change over time - so you are not likely to need the flexibility to change. Therefore using subcategory will acomplish what is needed.

I am interested in what some of the other developers think as I have seen some code which is written with logic based on device type (templates) where I would have thought it would have been better to use different patterns.

It might be better to code up your options and post the code fragments (or pseudocode) to get other developers to comment if you are still stuck for a design decision....

I'm getting nearer to actually implement code. I plan to make following changes to  Lighting plugin :

1. I'll change behaviour only for lighting switches (one being on/off and other being dimmable). The rest will stay as it is (this is I guess minimal disturbance - the only change is that lightswitch on/off device will have only on/off controls displayed  instead of all dimmmable as now)

2. I'll add possibility to use some other icon (floorplan objecttype) that will also be on/off device - this is currently a hack, so that one can use on/off devices also for control of other light related devices - I'll check first if this works at all...

3. I'll add support for gray color (predefined indicator color for dimmable state (between 0-100, with 0 and 100 not included).

4. I'll try to add better support for display on floorplan. Since state of device being on or off(100%) is easily recognized by color, I'll only put state info into floorplan string when device is in dimmable state (0<x<100). What I need is some help here further down the logic that currently doesn't write anything on floorplan regarding lighting devices, despite the fact that everything seems to be setup right in Lighting plugin (OSD string is the one that gets displayed for instance for Climate plugins)... Maybe this is a Designer related question, maybe those icons don't have proper container for text defined (I remember JonDecker talked about this some time ago)...

I'll be happy to hear further discussion on this matter...

Thanks in advance,

regards,

Bulek.

[bulek]

Hmm,

I'd still kindly ask for your discussion... In the mean time I got some nice results with similar changes on Climate Plugin. Therefore I guess similar features could be easily implemented in Lighting Plugin, but there is one major problem.

Altough it seems that OSD string is properly set up in plugin, nothing is showed on floorplan :

Code: [Select]

OSD = pDeviceData_Router->m_sState_get();

I suspect some kind of higher level is not using OSD to show it on floorplan. I just wonder where the problem is... Anyone with more insight ?

Thanks in advance,

regards,

Bulek.

[tschak909]

I think your approach is sound, I'm just not in that part of the code at the moment, so I can't give any feedback.

-Thom

[bulek]

I think your approach is sound, I'm just not in that part of the code at the moment, so I can't give any feedback.

-Thom

Hi,

Thom, would kindly ask if you can check it out on Designer's side... I suspect that maybe lights don't have defined area for displaying any text... Everything else on "my side of code" looks normal, so I guess the problems is somewhere higher towards Designer side...

It seems that Orbiter plugin also doesn't make any distinction among plugins, so lighting states should also be displayed but they aren't...

I also spotted some other problems (some command groups on floorplan don't work - for instance Sprinkler displays a lot of controls (on,off,5min,10min,....) but nothing happens when you click on them....

I can make a list of those and would be happy if anyone more familiar with Designer can check them out...

Thanks in advance,

regards,

Bulek.