MAX

[Bob B]

Snippet from fhem.cfg:
define MAX_LivingRoom MAX HeatingThermostat 130b46
attr MAX_LivingRoom userattr valveWeighting:[0:1] scnProcessByDesiChange:0,1 scnShutterList scnModeHandling:NOCHANGE,AUTO,MANUAL
...
attr MAX_LivingRoom valveWeighting 1.00
attr MAX_LivingRoom widgetOverride valveWeighting:slider,0,0.01,1,1

This is a real fhem/perl noob question!
See that valveWeighting ? It is just one parameter out of 5 (or more) that I  add to every MAX HeatingThermostat. It is difficult to maintain these userattr's as I add more devices. This is A Bad Thing because my control strategy and parameters change markedly as I get more familiar with the physical characteristics of MAX devices and my house and central heating system.

Philosophically, in my C/C++ mind, I just want to define my own class that inherits everything from a "MAX HeatingThermostat class"* but allows me to add my extra parameters and methods. I don't want to hack existing MAX / MaxScanner code which is working very well.

Any suggestions for a fhem/perl approach please?
Bob
*if such a class existed

[viegener]

HI Bob,
Unfortunately the model of FHEM does not contain the concept of derived classes as you suggest from an object oriented approach. So you can not create a daughter class of the actual device type including your specific variations, especially not with later syncing it on changes.

Even if this might be an interesting concept and I also sometimes miss such an "alignment" option for device settings, one way doing this inside FHEM would be to align this "manual" via FHEM commands using the device specification options to identify the affected devices,

While I agree, this being an interesting proposal, it is still the case, that I do not assume you will add hundreds of similar devices and even for many changes this would normally affect only the initial phase of a project heavily.

Best regards,
Johannes

[Bob B]

Hi Johannes,

Thank you very much for your comments; I think you have understood and answered my question perfectly.

... especially not with later syncing it on changes. ...

Yes, this would be a real problem.

... one way doing this inside FHEM would be to align this "manual" via FHEM commands using the device specification options to identify the affected devices,

I like this idea! I am thinking to add just one flag per device at device definition time (eg: when my CUL pairs with a new HeatingThermostat). After that I can manage additional attributes and methods myself. I can see a few small problems with this approach but it sounds good enough to get me going.

Kind regards,
Bob

[viegener]

Yes adding flags in some way will certainly help in identifying later. the gloabl attributes group and room are suitable for this, both of them can have multiple assigned values and therefore can be used to assign multiple "classification schemes".

I use rooms for stories in the buildings, administrative groups (e.g. devices that I usually would like to see on one page in fhemweb). While groups could be used for this as well, the number of schemes on my side is rather small and therefore rooms have been good enough for my needs.

In other cases selections are just based on type/subtype or even naming schemes.
Johannes

[Bob B]

Thank you for those ideas Johannes. I had not even considered rooms and groups as general purpose classifications. Simple and elegant!

Bob