I am a relative noob and currently debugging my custom icons. Mostly this works, e.g. for ON/OFF stuff.
But numerical values only seem to work for values smaller than 100.
I have a brightness sensor, which generates values between 0 and 255.
I have icons defined like “mybright.png”, “mybright-0.png”, “mybright-100.png”, “mybright-120.png”.
(no uppercase etc.)
There is no label text mapping in place just “…[%.0f]”.
The result is that I always see only the default “mybright.png” until the value goes smaller than 100, when I see “mybright-0.png”.
This is the same under iOS and BasicUI (set for bitmap).
The icons are in the same “icons/classic” folder like my other working ones.
And I have restarted openhab2.service and even rebooted many times. No go.
I am running an up-to-date openhabianpi (2.1.0-1) on a RPI3.
What you are doing seems to be correct. The best I can offer is to file an Issue with the Eclipse SmartHome project (I think that is where dynamic icons are implemented).
I really appreciate your support. Initially I had high hopes that someone would shout out with “works for me”. I’d never thought that values above 100 are somehow exotic. But it seems to me that the Slider is inherently limited to the range 0-100 (as opposed to the Setpoint widget, where you provide explicit min and max).
The value in question comes from a homematic motion sensor with integrated brightness sensor. This is bound via homegear and CUL. Am I right suspecting that the way to work aroud it it (i.e. mapping to range 0-100) would typically involve a virtual item?
Yes, a in this case we should call it a proxy item since it will act in place of the one linked to your device in your rules and sitemap. You will need a rule to keep them both in sync.
rule "calc scaled brightness"
when
Item MotionDetect_Brightness received update
then
if ((MotionDetect_Brightness.state >= 0) && (MotionDetect_Brightness.state <=255))
{
MotionDetect_Brightness_Scaled.postUpdate((MotionDetect_Brightness.state as DecimalType) / 2.55)
}
else
{
MotionDetect_Brightness_Scaled.postUpdate(UNDEF)
}
end
I think I almost understood the difference between update, command and change. In this case the item is read-only, so uni-directional synchronization does suffice. But due to the distinction between update and command a bi-directional synchronization might be doable as well.
received update triggers any time the item gets any sort of value though any means, even if that value is the same as the previous value.
changed triggers any time the state of the Item changes for any reason.
received command triggers only when a command is sent to an item
These triggers can be further specified in some cases. For example, for enum type items like switch and contact you can use received command ON or changed from OFF to ON. There is a bug that prevents this from working for String and Number items though.
The difference between an update and a command is that a command gets forwarded to the linked channel or binding and an update just changes the state of the item internal to OH. Whether an other gets commanded out updated from the binding is a decision left to the binding implementer. A rule of thumb is that sensors are updated and actuators are commanded.
Thanks for the clarification, especially about the “implementer is free to choose”.
So if I need to keep two items in sync. one “real”, one “proxy”, I’d need to avoid an endless loop of mutual triggering. If the binding updates the “real” item, I’d need an update trigger to detect it and then update my “proxy” item. When I change my “proxy” item manually, I’d choose to command it, and that trigger would command the “real” item, thus avoiding to hit the update trigger.
If the binding does it the other way round, I’d exchange update and command accordingly.
Just the opposite actually. A command to an Item will also trigger an update. A command is also an update and it requires an update for the Item to change so received update will trigger the rule any time anything is done to that Item for any reason in any way.
Typically and in all the cases I’m aware of the Binding will use a command to change the Item. But you will have to experiment with your specific binding to verify that the behavior.
But given the typical behavior, you would use postUpdate to change the state of your proxy item and trigger your rule using received command. If that doesn’t work it gets more complicated. Bult like I said, this almost always works.
Hmmm. I once more tried to read and understand the rules section of the user manual, especially: http://docs.openhab.org/configuration/rules-dsl.html#manipulating-item-states
The first time I read it I was not sure what was meant with the phrase about postUpdate: "Change the status of an Item without causing any implicit actions."
Now I suspect that “implicit action” is simply (and only!) the back-propagation of the binding to the real object.
So the system has some representation of the state of an item, and there are multiple parties throwing updates and commands on a kind of bus, so every party intercepts updates and commands from the others? With parties I mean at least:
the binding (reacting on command, but not on updates; generating both depending on implementation)
the gui (displaying all updates, generating commands on user input)
the trigger of rules (up to developer)
the body of rules (up to developer)
Is this “mutual interception” correct or is there any specific propagation mechanism in the system, which introduces a specific ordering or filtering?
That is correct. That is what that sentence is trying to say.
Yes, we refer to it as the Event Bus.
Yes. I’m not 100% certain of all the details but from a user’s perspective, the events propagate on the bus to all the parties you list plus one more, Persistence.
There is no way to filter the events short of how you define your Rule triggers which is a kind of filter. There is no way to guarantee order of processing of events that occur really close together.
Sorry to reply on this older post. I think I misinterpreted your statement. With “The best I can offer”, did you mean to offer that you would forward this issue to ESH issues system? This is what I understood initially. Or did you mean that as your best proposal to me, so I would file a bug there on my behalf. This is what I understand when I read it today…
Today I tried to find the issue system of ESH, but neither did I find this icon issue there, nor did I find a lot of traffic and a huge number of different users/committers. And after a week of playing with openHAB configuration, I feel more equipped to file a bug myself and get the terms right.
Actually, I meant the best I can offer is to suggest you file the issue. I’m hesitant to open issues for others because I do not have the full experience nor a setup OH environment to reproduce the error or run any tests the devs may need to further understand the problem.
I have the same kind of problem with negative value: for weather temperature for example. While ESH try to provide a solution, has anyone got a suggestion to map negative values to dynamic icons?
yep, there is the obvious problem that the - is reserved for dynamic icons, but a negative number must be -xx which conflicts with the rule. i wanted to check if maybe -n05 for example works for negative 05… but i didnt find the time to do so since i need to get a temperature below 0.
