Why nothing is displayed on floorplan for lighting devices (perhaps other also)?

[bulek]

Hi,

I've done successfully some enhancements in Climate Plugin. Now you gain more control what is displayed on floorplan :
http://wiki.linuxmce.org/index.php/Climate_Plugin#Description_of_enhanced_710_plugin_and_ability_to_control_displayed_info_on_floorplans

Now I'd like to do something similar also for other plugins, Lighting being the first in focus.... But the problem is that currently nothing is shown for lighting devices on lighting floorplan. Although it seems that lighting plugin is setting OSD string correctly (content of that string determines info displayed on floorplan) - but nothing is displayed. I'm trying to find the cause, but also Orbiter plugin seems to do nothing special about it...

So I suspect that something is maybe wrong even on higher level (maybe lighting devices as design objects don't have a text display defined?) ?

I'd kindly ask if Tschak, or anyone more familiar with "Designer's" side of LMCE can check the things out.

Basic question is: if lighting device has a state of "ON/100" why nothing is displayed on floorplan beside icon ?

If we find the cause of problem, maybe it wouldn't be bad to check also for other plugins (beside Climate that already works quite well)...


Thanks in advance,

regards,

Bulek.

[tschak909]

I will have to check the code when I get back to shore..but Look in Designer to make sure that there are appropriate variable substitutions in the appropriate DesignObjs.

-Thom

*does-the-i'm-chillin-in-the-carribean-and-ya'll-are-not-dance*

[maybeoneday]

*does-the-i'm-chillin-in-the-carribean-and-ya'll-are-not-dance*

How DARE you have time off  !!!     

Enjoy, you deserve it,

HAPPY HOLIDAYS TO ALL

best regards,
Ian

* Ian does the freezing testicles dance in UK  *


 ( btw can't you find anything better to do in carribean than check posts ?     )

[bulek]

I will have to check the code when I get back to shore..but Look in Designer to make sure that there are appropriate variable substitutions in the appropriate DesignObjs.

-Thom

*does-the-i'm-chillin-in-the-carribean-and-ya'll-are-not-dance*

Hi,
Tschak have a great time...

Is anyone else deeper in Designer right now and can check these things ?

I know, I'll learn Designer also some day, but currently I'm doing job in Lighting and Climate plugins....

Thanks in advance,

Regards,

Bulek.

Update: Tschak, are you back from vacation ? I'd kindly ask if you can check things on rendering side....

[jondecker76]

Bulek

I was going to tackle the same problem some time back, but when things picked up at work I've hardly had a spare moment until recently... But, working off of memory...

-In Lighting_Plugin, you want to look at Lighting_Plugin::GetFloorplanDeviceInfo. This handles all floorplan interactions. As you will see when you look at the source, the OSD variable is set as it should be!

-The "bug" where text is not getting rendered is actually in HaDesigner. If I can remember correctly, look at the various lighting floorplan icons in HaDesigner. The icons are in a sort of container( a clipping region) that must be stretched to fit both the icon and the text. I can't recall off hand if the text substitution is already there or not, but I believe it was... (compare them to the Climate floorplan icons, it will make more sense) It is a simple edit of the icons in HaDesigner that will enable the OSD to be visible on the floorplans for light objects. There is a bug (At least there was at the time) where you could not place the OSD text below the icon however (which would save most room on the floorplan) due to the offset of the vertical size of the icon not being taken into account when rendering. I remember hearing though that the bug was fixed. If the bug was indeed fixed, text layout would be most sensible BENEATH the icon (same goes for Climate floorplan icons).
It would be a good thing for you to install HaDesigner just for the learning, it will help it make more sense.
Also, remember that the clipping region set in HaDesigner is constant, so any string too long will be chopped off, so it should be sized to the longest expected string (within reason of course)

While on the Lighting_Plugin subject, other things to fix are: (and I would like to help you with)
1) Again, looking at Lighting_Plugin::GetFloorplanDeviceInfo..
PK_DesignObj_Toolbar=DESIGNOBJ_grpLightControls_CONST; -< this line
The toolbar object should have its own conditional to decide whether to display grpLightControls (with dimming controls) for lights that support dimming, or grpLightControlsOnOff for lights that don't support dimming. This should be as simple as checking the device template to see if the Dimming command group is enabled. Also, for blinds, you can even use a different command group with "Open" and "CLose" buttons.

2) For the OSD, I think instead of showing something like "On/100" (state/dimLevel), do the following:
(pseudo code)
If light is On and DimLevel = 100%
     OSD = "ON"
else if Light is On and DimLevel is between 1 and 99
     OSD = DimLevel + "%"
else if light is Off
     OSD = "OFF"

3) Go back over Climate_Plugin and implement the same type of logic to display appropriate toolbars depending on the device

I'll be around here all weekend and on IRC, I'd love to work with you on this. (now that I finally have some time again)



and a last side note...
OSD is very useful for Climate devices..  They aren't so useful for the Lighting devices (the icon color shows state of off and on without text).. The only thing to gain is seeing the dimLevel. While I like your string replacement idea, realize that its utility will be limited in Lighting_Plugin.

[Techstyle]

I will have to check the code when I get back to shore..but Look in Designer to make sure that there are appropriate variable substitutions in the appropriate DesignObjs.

-Thom

*does-the-i'm-chillin-in-the-carribean-and-ya'll-are-not-dance*

I was also in the Carribean over Chrsitmas. Negril, Jamaica, where were you Thom?

back in Milwaukee now - freezing my nuts off

[bulek]

thanks for info, comments below...

Bulek

I was going to tackle the same problem some time back, but when things picked up at work I've hardly had a spare moment until recently... But, working off of memory...

-In Lighting_Plugin, you want to look at Lighting_Plugin::GetFloorplanDeviceInfo. This handles all floorplan interactions. As you will see when you look at the source, the OSD variable is set as it should be!

-The "bug" where text is not getting rendered is actually in HaDesigner. If I can remember correctly, look at the various lighting floorplan icons in HaDesigner. The icons are in a sort of container( a clipping region) that must be stretched to fit both the icon and the text. I can't recall off hand if the text substitution is already there or not, but I believe it was... (compare them to the Climate floorplan icons, it will make more sense) It is a simple edit of the icons in HaDesigner that will enable the OSD to be visible on the floorplans for light objects. There is a bug (At least there was at the time) where you could not place the OSD text below the icon however (which would save most room on the floorplan) due to the offset of the vertical size of the icon not being taken into account when rendering. I remember hearing though that the bug was fixed. If the bug was indeed fixed, text layout would be most sensible BENEATH the icon (same goes for Climate floorplan icons).
It would be a good thing for you to install HaDesigner just for the learning, it will help it make more sense.
Also, remember that the clipping region set in HaDesigner is constant, so any string too long will be chopped off, so it should be sized to the longest expected string (within reason of course)

I'd love to do this, but would prefer to focus my efforts on at least getting same philosophy of display support into Climate and Lighting plugin (I'd also like to implement possibility to define replacement for known standard strings for state - for instance you could replace HEAT on floorplan with something completely customized : START for instance). My time is pretty limited...

Is there any chance to package this fix in any form that could be used without HaDesigner ? I know I have to do this, but would like to do it after 810 and fixes in those plugins...

While on the Lighting_Plugin subject, other things to fix are: (and I would like to help you with)
1) Again, looking at Lighting_Plugin::GetFloorplanDeviceInfo..
PK_DesignObj_Toolbar=DESIGNOBJ_grpLightControls_CONST; -< this line
The toolbar object should have its own conditional to decide whether to display grpLightControls (with dimming controls) for lights that support dimming, or grpLightControlsOnOff for lights that don't support dimming. This should be as simple as checking the device template to see if the Dimming command group is enabled. Also, for blinds, you can even use a different command group with "Open" and "CLose" buttons.

2) For the OSD, I think instead of showing something like "On/100" (state/dimLevel), do the following:
(pseudo code)
If light is On and DimLevel = 100%
     OSD = "ON"
else if Light is On and DimLevel is between 1 and 99
     OSD = DimLevel + "%"
else if light is Off
     OSD = "OFF"

3) Go back over Climate_Plugin and implement the same type of logic to display appropriate toolbars depending on the device

I'll be around here all weekend and on IRC, I'd love to work with you on this. (now that I finally have some time again)



and a last side note...
OSD is very useful for Climate devices..  They aren't so useful for the Lighting devices (the icon color shows state of off and on without text).. The only thing to gain is seeing the dimLevel. While I like your string replacement idea, realize that its utility will be limited in Lighting_Plugin.

of course, but this will allow control of what is displayed on floorplan. I find this feature usable - for some specific light devices I'll simply put some text description beside it (icon is not always enough)... This will also be useful for Security and Telecom devices, once they will have proper state info....

I'm more interested in your opinion, whether such implementation is acceptable solution. I'd just like to add feature of string replacement

'$1/$2/$3/$4 ($5) ?$3|HEAT|High?$3|COOL|Low'

so for instance State of HEAT in $3 will be shown as High on floorplan, but I'm learning C++, so will be happy if someone will lend a hand....

If implementation is acceptable, we could stretch it into other floorplan showing plugins and also prepare some basic set of fully supported floorplan devices (currently most missing in my house are Blinds, Shutters, Drapes, Climate Simple Input, Simple Output (on/off), etc...) for 810 release. This will make LMCE usable also for proper home automation control....

Regards,

Bulek.

[jondecker76]

these changes must be made in HaDesigner - it is entirely related to the designObj layout. I can change these, commit the changes, and then you could use sqlcvs to pull the changes into your install. However, with so much work going in on the 0810 release, we would have to get the blessing from some of the bigger devs before messing with any of the designObj tables.

Again, the support is there already, regardless of whether the OSD on the floorplan is showing. If you delete the picture floorplan, you will get the datagrid version, which will display the OSD for you for testing purposes so you know how your string replacement is working.

As far as string replacement - I think what is needed is much more complex. A simple lexer comes to mind - one that supports some simple tags (like <%state%>, <%mode%>, etc), assignment, comparative operations (=, <, >, <>), a simple PHP-like if statement, and simple text. They your device data can look like:
"Temperature:" + <%temperature%> > 80 ? "Hot" : "Cold"

(if the temperature > 80 degrees, then "Temperature: Hot" would be displayed. Else, "Temperature: Cold" would be displayed.)

Embedded Ruby could work, but I have no experience with that.

SImple string replacement is still ok, just not very flexable. Catch me on IRC over the next few days, we'll talk about it

[jondecker76]

Doing some more thinking out loud... I now remember why I didn't implement such a simple feature earlier.... Limitations of the system... Read on:

An embedded language or lexer/parser/scripting language seems a little overboard. I see 2 very feasible, and easy to implement options that make a lot more sense:

1) Simply do better filtering of the OSD variable in the individual plugins. For example, if the floorplan object type is a thermometer, just show the temperature portion of the state variable. If the floorplan object type is a light, show either "On", "Off" or the percentage if its dimmed. This is the cleanest and most predictable way to clean up the floorplan.

2) Simple text replacement could work and is more feasible than a scripting language. Having it tag based makes most sense though (<%temperature%>, etc). Then you can have some custom text as well

While a full scripting language would give you power to change icon color, text color etc dynamically based on on of the state variables, there are inherited limitations that make it not so useful. As I said before, the designobj has a pre-defined clipping area. Therefore, it can only display so much text before it is lost outside of the clipping boundary. Making each designobj overly large to compensate for this only complicates things more as you will run into overlapping designobjs and the artifacting that it causes. So in reality, OSD text needs limited to about the same width or height as the icon its self, which is very small (probably only good for 10 characters tops). This limitation alone is enough to show that all the power of embedded scripting would be negated by how the system is already designed. This is why choice#1 above is the best route. It is clean, and the text can be guaranteed to fit, and the designobjs can be sized accordingly. Also for this reason, OSD text should be displayed below the icon to take up as little space as possible. This is why you really should install HaDesigner - once you see this limitation in person, you will see what you are up against. I just don't see what there is to gain with text replacement if the most you could get out of it with a reasonable designobj size is an OSD string like "Temp: 70"

There are still other things that can be improved though (an iconColor deviceData, a textcolor devicedata, etc)


I'll try to post a screenshot later so you can see the OSD text/icon bounding box problem, and give you ideas on what kind of screen realistate we actually have to work with.

[bulek]

these changes must be made in HaDesigner - it is entirely related to the designObj layout. I can change these, commit the changes, and then you could use sqlcvs to pull the changes into your install. However, with so much work going in on the 0810 release, we would have to get the blessing from some of the bigger devs before messing with any of the designObj tables.

Again, the support is there already, regardless of whether the OSD on the floorplan is showing. If you delete the picture floorplan, you will get the datagrid version, which will display the OSD for you for testing purposes so you know how your string replacement is working.

As far as string replacement - I think what is needed is much more complex. A simple lexer comes to mind - one that supports some simple tags (like <%state%>, <%mode%>, etc), assignment, comparative operations (=, <, >, <>), a simple PHP-like if statement, and simple text. They your device data can look like:
"Temperature:" + <%temperature%> > 80 ? "Hot" : "Cold"

(if the temperature > 80 degrees, then "Temperature: Hot" would be displayed. Else, "Temperature: Cold" would be displayed.)

Embedded Ruby could work, but I have no experience with that.

SImple string replacement is still ok, just not very flexable. Catch me on IRC over the next few days, we'll talk about it

I agree this would be best, but currently we have only c++ coded plugins... So for a start, I think having feature as I have now is quite a step forward.

I'll make those changes and probably replace $x with more meaningful strings like you proposed.

regards,

Bulek.