PercentType for NumberItem

[Felix Ide]

Hello,

after a long time i finally got some spare time to work again on my
openHab installation :-) I would like to display the status of my
heating actuators (Heimeier EIB). The status value is a 5.001
(Percentage 0-100), but on update I get
"Received update of a not accepted type (PercentType) for item
Heizung_EG_Buero_Status"
error messages. Would it be best to extend NumberItem so that it accepts
PercentType or do you have an other/better idea?

Regards,
Felix

[Kai Kreuzer]

Hi Felix,

How about using a DimmerItem, would that do for your use case?

Regards,
Kai

> --
> You received this message because you are subscribed to the Google Groups "openhab" group.
> To post to this group, send email to ope...@googlegroups.com.
> To unsubscribe from this group, send email to openhab+u...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/openhab?hl=en.
>

[Felix Ide]

Hi Kai,

a DimmerItem is not an option since I only want to display the values.
After looking at the code I saw that NumberItem accepts DecimalType, and
PercentType is (from an OOP view) DecimalType. So it schould accept it
also (and of course it works like a charm if you add PercentType to the
accepted types of NumberItem).
It is not accepted now because the decison is only based on the class
name, not on the class hierarchy. I think the logic should respect class
hierarchy, what do you think? Do you see any combinations why this
should not apply?
If you agree I could change the implementation.

Regards,
Felix

[Kai Kreuzer]

Hi Felix,

> a DimmerItem is not an option since I only want to display the values.

The item type has nothing to do with how you display it in the UI. You can easily use a Text widget with an DimmerItem (i.e. you will only see the value, but no buttons).

> It is not accepted now because the decison is only based on the class name, not on the class hierarchy. I think the logic should respect class hierarchy, what do you think? Do you see any combinations why this should not apply?
> If you agree I could change the implementation.

Yes, you are right, this would be cleaner. I cannot think of a situation right now where this could lead to a problem. So feel free to provide a patch (resp. changeset in a clone repo).

Cheers,
Kai

[Felix Ide]

Hi Kai,

>> a DimmerItem is not an option since I only want to display the values.
> The item type has nothing to do with how you display it in the UI. You can easily use a Text widget with an DimmerItem (i.e. you will only see the value, but no buttons).

Agreed :)

>> It is not accepted now because the decison is only based on the class name, not on the class hierarchy. I think the logic should respect class hierarchy, what do you think? Do you see any combinations why this should not apply?
>> If you agree I could change the implementation.
> Yes, you are right, this would be cleaner. I cannot think of a situation right now where this could lead to a problem. So feel free to provide a patch (resp. changeset in a clone repo).
>
> Cheers,
> Kai

Ok, I will look for a clean way to implement this.

Regards,
Felix

[Felix Ide]

Hi Kai,

I have created a new branch TypeHierarchy in my clone felixide-openhab.
If you like the changes feel free to merge, otherwise I am open for any
critcism.

Regards,
Felix

PS: Is it the preferred way to publish changes in a branch of a clone?
Or what would you suggest?

[Thomas Eichstädt-Engelen]

Hi Felix,

PS: Is it the preferred way to publish changes in a branch of a clone? Or what would you suggest?

yes, please add a feature-branch for each new feature in your clone. That makes merging to main repo as easy as possible ...

Thanks,

Thomas E.-E.

[Kai Kreuzer]

Hi Felix,

I have created a new branch TypeHierarchy in my clone felixide-openhab. If you like the changes feel free to merge, otherwise I am open for any critcism.

Thanks for this! I just have a short question:

Could the line

if (!state.isEnum() && state.newInstance().getClass().isAssignableFrom(newStatus.getClass())) {

not be replaced by

if (!state.isEnum() && state.isAssignableFrom(newStatus.getClass())) {

Is there any reason that I miss, why you have to create a new instance of the state?

PS: Is it the preferred way to publish changes in a branch of a clone? Or what would you suggest?

Yes, absolutely the preferred way!

Regards,

Kai

Am 18.11.2012 21:51, schrieb Felix Ide:

Hi Kai,

a DimmerItem is not an option since I only want to display the values.

The item type has nothing to do with how you display it in the UI. You can easily use a Text widget with an DimmerItem (i.e. you will only see the value, but no buttons).

Agreed :)

It is not accepted now because the decison is only based on the class name, not on the class hierarchy. I think the logic should respect class hierarchy, what do you think? Do you see any combinations why this should not apply?
If you agree I could change the implementation.

Yes, you are right, this would be cleaner. I cannot think of a situation right now where this could lead to a problem. So feel free to provide a patch (resp. changeset in a clone repo).

Cheers,
Kai

Ok, I will look for a clean way to implement this.

Regards,
Felix

[Felix Ide]

Hi Kai,

no, because getAcceptedDataTypes() returns a list of Class<? extends
State>. Because of type erasure when you would just call
state.getClass() you would only get java.lang.Class, not the real
implementing class.

Regards,
Felix

Am 24.11.2012 22:29, schrieb Kai Kreuzer:
> Hi Felix,
>
>> I have created a new branch TypeHierarchy in my clone
>> felixide-openhab. If you like the changes feel free to merge,
>> otherwise I am open for any critcism.
>
> Thanks for this! I just have a short question:
>
> Could the line

> *if (!state.isEnum() &&
> state.newInstance().getClass().isAssignableFrom(newStatus.getClass())) {*
> not be replaced by
> *if (!state.isEnum() && state.isAssignableFrom(newStatus.getClass())) {*

>> <mailto:ope...@googlegroups.com>.

>> To unsubscribe from this group, send email to
>> openhab+u...@googlegroups.com

>> <mailto:openhab+u...@googlegroups.com>.