[FHZ] Introducing EnvSens & Call for Discussion

[Dr. Boris Neubert]

                                             

Am 07.02.2010 15:17, schrieb Kai 'wusel' Siering:
> Dr. Boris Neubert wrote:
>
>
> If you haven't asked the question, I would have; if FHEM *is* object-
> orientated, *then* it lacks quite a few interfaces to make use of an
> object model. No one, not even a module itself, currently knows what
> it does, what it provides (except for SETables). There should be
> classes from which the actual device inherits basic properties -- for
> especially the benefit of any UI.

please do not confuse the concepts of inheritance and interfaces.
Inheritance is appropriate for devices where one is a more specialized
version of another, e.g. FS20 switch -> FS20 dimmer. X10 devices and
FS20 devices have no common ancestor but they share some functionality
from the user's point of view which could be standardized by interfaces.
>
> Well, ok, there *are* classes, today, e. g. the class CUL_WS, the class
> HMS, the class FS20, ... That's were the object-orientation vanishes, to
I would not take the modules for classes in the sense I used previously.
The modules merely bundle the device access layers for a family of devices.
>> We introduce interfaces ("interface" as "interface in object-oriented
>> programming", not as "interface of a physical device") and enhance
>> the status of the "model" attribute. FS20 and X10 switches implement
>> the "switch" interface, FS20 and X10 dimmers implement a "dimmer"
>> interface, in addition to the "switch interface", weather stations
>> and 1-wire-temperature sensors implement the "thermometer" interface.
>> The consumers of the modules, i.e. the user interfaces, query the
>> interfaces for a device and decide how to present them to the user,
>> how to order them in rubrics, etc. This would, by the way, also
>> address the calls for a more harmonized naming of readings - a device
>> that implements the "thermometer" interface has a reading named
>> "temperature" as this is part of the interface declaration.
>
> Thanks! I rather like it, as it yields the desperately wanted func-
> tionality; and being less intrusive, it'd be a far more viable so-
> lution.
So how could this be achieved?

Boris

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

[rudolfkoenig]

                                                   

> We introduce interfaces ("interface" as "interface in object-oriented
> programming", not as "interface of a physical device") [...]

I like this idea better, at least I understand it, contrary to EnvSense . In
my opinion it is noth worth defining the interfaces (not an easy task) and then
rewriting ca 50% of the fhem code. Consolidating the readings/settings would be
easier.

But if somebody has the energy to do it, then he should look at the KNX
definition: AFAIK it has a classification with well defined interfaces. This
would help to integrate KNX modules / bridges in fhem, and as I was told an
electrician master has to absolve a KNX course, so talking with them would be
easier.

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

[Guest]

Originally posted by: <email address deleted>

Hi,

Olaf Droegehorn wrote:

> For the front-ends it's superb, if you can bring the info's from
> different modules together.

Thanks for the input from your view at/of FHEM.

What puzzles me: doesn't it bother you -- or the poeple for whom you
supply installation and/or the frontend --, that you need to keep up
with current developments and expand your frontend to the second,
then third, fourth switchable power outlet type, simply because there
are no means to find out what kind of device $hash actually is if you
don't know about it's TYPE NewDevice yet?

As, as a user, I would be rather pissed if I googled before buying,
found out e. g. FHEM now supports SIS power bars -- and then find
that, while FHEM does support those, no frontend knows nor cares
about 'em. They aren't shown as switchable sockets, they can not
be clicked on to switch (like, e. g. FS20-STs).

I'm truly puzzled that this hasn't even been addressed by front-
end workers yet. Interessting.

> For harmonization, well .....
> There's always a need for doing things in the same way for different
> modules. But as this is an open community, and not a paid development,
> everybody should be free to provide functionality as he/she likes.

Sure, there's always the possibility to fork

> Therefore I'm still in favour of the module concept for each single
> device, and think that the front-end guys can bring those things
> together if they like.

It doesn't make much sense for someone (new) to make the effort
of writing the FHEM-modules for a new device if there's no-one
actually able to use it, author included, does it? By "using" I
mean "in the frontend of his or her choice". What's worse, the
author can't even support the UI writers in any way from within
his module. Each and any UI writer has to actively adopt support
for every new module -- afterwards. Think about HS485; there
seems to be success, but there's no module, yet, in the FHEM CVS.
So, no frontend can handle HS485 devices today nor at the day of
HS485's release -- even if it would like to.

> For EnvSens:
> What's about users context / BT-Recievers, Cellar-Water, Gas, etc.
>
> This all would fit into EvSens, right ? Where does this end ? Just one
> monolithic block.

Does it. Don't know. Water, Gas, etc. I's expect them supported by
MeasuringSens.pm. BT receivers that receive temperatures from sensots
via BT? EnvSens, certainly. BT receivers that receive command from
a remote control? RemoteControls.pm (first candidate: LIRC ). As
for "user context", I don't understand that there. PIRs would fit
in EnvSens, ack.

> Therefore I would vote for the module structure, as we have it now.

Thanks, noted.

Ciao,
         kai

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

[Guest]

Originally posted by: <email address deleted>

Dr. Boris Neubert wrote:
 >> If you haven't asked the question, I would have; if FHEM *is* object-
 >> orientated, *then* it lacks quite a few interfaces to make use of an
 >> object model. No one, not even a module itself, currently knows what
 >> it does, what it provides (except for SETables). There should be
 >> classes from which the actual device inherits basic properties -- for
 >> especially the benefit of any UI.
 >
 > please do not confuse the concepts of inheritance and interfaces.
 > Inheritance is appropriate for devices where one is a more specialized
 > version of another, e.g. FS20 switch -> FS20 dimmer. X10 devices and
 > FS20 devices have no common ancestor but they share some functionality
 > from the user's point of view which could be standardized by interfaces.

Ah. Well, I though along the lines of having a generic set of devices
with a basic command set each. An actual device would be an anchestor of
one or more of them, therefore they inherit the (joint) commands (and
properties implied, e. g. that a device of family sensor can't be set
to a given value).

That's what EnvSens is doing. The device class EnvSens features sensors,
they can be read (implied by definition). What kind of exactly is to be
read from explanatory settings (DEVTYPE, DEVFAMILY, SENSTYPE).

So, if I understand you corrently, you're proposing to introduce simply
something along these lines?

   $hash->{INTERFACES}="FHT80b:temperature";          # for an FHT80b
   $hash->{INTERFACES}="sensor:temperature:humidity"; # e. g. S300TH, HMS100TF
   $hash->{INTERFACES}="switch:write-only";           # e. g. an FS20-ST
   $hash->{INTERFACES}="sensor:energy";               # e. g. ES-1/EM1000EM
   $hash->{INTERFACES}="switch:read-write;sensor:energy"; # e. g. Plugwise Circle
   $hash->{INTERFACES}="switch:write-only:dimmer:write-only"; # e. g. an FS20 dimmer

(Maybe with a better syntax )

 >> Well, ok, there *are* classes, today, e. g. the class CUL_WS, the class
 >> HMS, the class FS20, ... That's were the object-orientation vanishes, to
 >
 > I would not take the modules for classes in the sense I used previously.
 > The modules merely bundle the device access layers for a family of devices.

 From my perspective, this has the *effect* of defining classes in the UIs.
But it may be a battle about words.

 >>> We introduce interfaces ("interface" as "interface in object-oriented
 >>> programming", not as "interface of a physical device") and enhance
 >>> the status of the "model" attribute. FS20 and X10 switches implement
[...]
 >>> how to order them in rubrics, etc. This would, by the way, also
 >>> address the calls for a more harmonized naming of readings - a device
 >>> that implements the "thermometer" interface has a reading named
 >>> "temperature" as this is part of the interface declaration.
 >>
 >> Thanks! I rather like it, as it yields the desperately wanted func-
 >> tionality; and being less intrusive, it'd be a far more viable so-
 >> lution.
 >
 > So how could this be achieved?

Rudolf Koenig wrote:

> I like this idea better, at least I understand it, contrary to EnvSense . In
> my opinion it is noth worth defining the interfaces (not an easy task) and then
> rewriting ca 50% of the fhem code. Consolidating the readings/settings would be
> easier.

Trying not to be rude, but ... well. By just consolidating the readings, what
is gained in terms of identifying one modules "interfaces" (or capabilities
or properties or ... call it as you like)?

Let me try it the other way around: pgm2 discovers something with $hash->{TYPE}
being "WSP4713". Please tell my how do you present the _correct_ UI for this
device (is is similar to others, already supported ones), based on ideal
"readings/settings".

It's not about consolidating readings. Sure, you could write some lengthy if
defined(this) then assume that elsif ... kind of code.

If there was $hash->{INTERFACES} containing e. g. "switch:read-write;sensor-
:energy;sensor:temperature", you *would know*, no need to *guess*.

(The "EnvSens approach" just shortcuts that: Every supported sensor served
by EnvSens.pm has $hash->{TYPE} "EnvSens"; which means it's a sensor and the
kind can be computed from a combination of (3) other variables, if needed.
Again, no need to guess, it is clearly identified. Like you used to know
how to handle "CUL_WS", "HMS", "KS300", you'd now know how to handle "Env-
Sens" devices instead. But while you never dreamt of a WS4713, as EnvSens.pm
was extended to support it, you instantly know how to handle it as well ...)

> But if somebody has the energy to do it, then he should look at the KNX
> definition: AFAIK it has a classification with well defined interfaces.

Not needing to re-invent would be great. But unless it's agreed that these
to-be-discussed changes will happen and frontends will actually use them,
I'm afraid it's not worth the hassle.
         kai

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

[nobody0472]

                                                                 

Hi again,

commtens inline

> Olaf Droegehorn wrote:
> > For the front-ends it's superb, if you can bring the info's from
> > different modules together.
>
> Thanks for the input from your view at/of FHEM.
>
> What puzzles me: doesn't it bother you -- or the poeple for whom you
> supply installation and/or the frontend --, that you need to keep up
> with current developments and expand your frontend to the second,
> then third, fourth switchable power outlet type, simply because there
> are no means to find out what kind of device $hash actually is if you
> don't know about it's TYPE NewDevice yet?
>
> As, as a user, I would be rather pissed if I googled before buying,
> found out e. g. FHEM now supports SIS power bars -- and then find
> that, while FHEM does support those, no frontend knows nor cares
> about 'em. They aren't shown as switchable sockets, they can not
> be clicked on to switch (like, e. g. FS20-STs).
>
Well, no problem here, for some reasons:

1) Most of the guys build their own front-end with exactly THEIR
devices, so everything is fine;
2) For those using standard front-ends, most of those guys are using
standard components (FS20): No Problem;
3) Those guys, who like to experiment (as they already know what's
supported, and what's not) are able to write new stuff, or add stuff
somewhere, so: No Problem;
4) Some clever guys even ask before start bying things, what's
supported; So: No Problem

Sorry for that, but most of the people like the appraoch, and are
happy, when open source projects are moving at all.
Therefore they welcome what's already there. And we HAVE a lot
already, that is working fine.

And for front-ends: Even unknown devices are visible, even if not very
nicely. And if this really hurts somebody, they know, that they are
invited to update every frontend-code to help us.

Nevertheless, harmonizing READINGS and SETs/GETs is a perfect idea,
and I would be in favour to have rough guidelines how to write
modules.
Beyond that; I'm fully happy with whatever kind of module might
appear, and I will take it (or not) into account for my frontends.
And if somebody supplies code for my frontend, even better

Cheers,
Olaf

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

[rudolfkoenig]

                                                   

> Let me try it the other way around: pgm2 discovers something with $hash->{TYPE}
> being "WSP4713". Please tell my how do you present the _correct_ UI for this
> device (is is similar to others, already supported ones), based on ideal
> "readings/settings".

pgm2 currently shows the "unknown" device, its status in the summary, all of
its readings and all possible sets and attributes in the detail view.

In order to remove special device handling currently present in pgm2, this
could be extended with all gets and an "important" set (on/off or desired
temperature) for the summary.

The current "interface" is simple: each device has to tell each of its
readings/possible attributes and settings, and its status. It is not perfect,
but it is simple (which IMHO is more important), making the barrier low for
everybody to enter. Even the frontend author has less work to do, as it does
not have to write special code for each interface.

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

[Guest]

Originally posted by: <email address deleted>

Rudolf Koenig wrote:
>> Let me try it the other way around: pgm2 discovers something with $hash->{TYPE}
>> being "WSP4713". Please tell my how do you present the _correct_ UI for this
>> device (is is similar to others, already supported ones), based on ideal
>> "readings/settings".
>
> pgm2 currently shows the "unknown" device, its status in the summary, all of
> its readings and all possible sets and attributes in the detail view.

So, do you agree that, with the knowledge of the kind of device, a more
correct summary view could easily presented? That's what the "interfaces"
would be about ...

> The current "interface" is simple: each device has to tell each of its
> readings/possible attributes and settings, and its status. It is not perfect,

I find it rather great for now, unfortunately I don't know the syntax
for GET; for SET it became clear by try-and-error in the dropdown
         kai

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

[Dr. Boris Neubert]

                                             

Am 07.02.2010 18:13, schrieb Kai 'wusel' Siering:
> So, if I understand you corrently, you're proposing to introduce simply
> something along these lines?
>
>     $hash->{INTERFACES}="FHT80b:temperature";          # for an FHT80b
>     $hash->{INTERFACES}="sensor:temperature:humidity"; # e. g. S300TH,
> HMS100TF
>     $hash->{INTERFACES}="switch:write-only";           # e. g. an FS20-ST
>     $hash->{INTERFACES}="sensor:energy";               # e. g.
> ES-1/EM1000EM
>     $hash->{INTERFACES}="switch:read-write;sensor:energy"; # e. g.
> Plugwise Circle
>     $hash->{INTERFACES}="switch:write-only:dimmer:write-only"; # e. g.
> an FS20 dimmer
>
yes, that's it. By virtue of yet-to-be-written specs, a device with
"dimmer" turning up in $hash->{INTERFACES} is guaranteed to be able to
be set "on" and "off" and the readings contain something like a status
reading which is either "on" or off. Or for a device with "thermometer"
in $hash->{INTERFACES}, there is again, by virtue of the specs, for sure
a reading "temperature" which contains a floating point number (without
"°C" or "(Celsius)" or the like). If I am not mistaken all this could be
added without breaking existing user interfaces at all.

> Rudolf Koenig wrote:
>
>> I like this idea better, at least I understand it, contrary to
>> EnvSense . In
>> my opinion it is noth worth defining the interfaces (not an easy
>> task) and then
>> rewriting ca 50% of the fhem code. Consolidating the
>> readings/settings would be
>> easier.
>
> Trying not to be rude, but ... well. By just consolidating the
> readings, what
> is gained in terms of identifying one modules "interfaces" (or
> capabilities
> or properties or ... call it as you like)?

Consolidating the readings is a spin-off from adhering to specs. If you
look at the DbLog module you can see through what pains one has to go to
normalize the readings for coherent use.
> Sens" devices instead. But while you never dreamt of a WS4713, as
> EnvSens.pm
> was extended to support it, you instantly know how to handle it as
> well ...)
In the WS4713 module, just publish the interfaces WS4713 provides and
you are done. The user interfaces will know what to do.

Extending EnvSens.pm would end up in a monolithic approach with one fat
module that cannot be maintained any more.  And what about different
devices with overlapping functionality, e.g. a thermostat? Does such a
device "inherite" from EnvSens (because it has a temperature reading) or
from Switch (because it turns things on and off)? There are good reasons
for multi-class-inheritance not existing in modern programming languages
in favor of interfaces that can easily circumvent such conflicts in a
natural way.

Before I open the "call for interface specs" thread I would like to hear
opinions from others, both from the module programmers and from the ui
developers.

Best Regards,
Boris

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

[Guest]

Originally posted by: <email address deleted>

Hi,

I'd like to hearthfully thank anyone who participated in this
discussion, yet.

As it seems, I somehow messed up the motivation of proposing
"EnvSens"; I'd like to take the opportunity to re-phrase that,
based on input during the last few days.

Please don't hesitate to comment further, it's not over yet

*Motiviation*: having adopted the WS3600/WS2300 weather stations,
the FHT80TF and the Silvershield Power Manager usb-controllable
power bar for FHEM, among others, I find that none of "my" devices
are actually showing up in any frontend in the way they should (if
at all).

I'll make it short: this is because there are no provisions in FHEM
(yet?) to support yet unknown devices. They are as per definition
just black boxes.
I don't like that. I'd like to have any UI to know whether $hash is
a sensor, an actor; but it's not possible in FHEM as of now. I see
not much sense in creating support for devices that cannot be used
apropriately, not after having someone else to update his UI code
as well.
Thus I did the usual thing, throwing away what's of no use any more
(tons of identical functioning code in separate modules) and merge
what is useful into something new. Takes less than an afternoon, and
the result is rather pleasing: EnvSens, a framework which enables any
frontend to happily work with *any* new sensor I or someone else
comes up with. Out of the box. It's just beautiful

Well, unfortunately, it has some "minor implications" , thus I'd
ask for this discussion.



*Intermediate summary*: there were, not surprisingly, strong votes against
this approach.

Arguments agaist, in no specific order (some were approximately translated or
(hopefully) apropriately shortened):

  - "I don't like the approach to put anyting into one module"
  - "I don't think a user wants to see all sensor data 'at once'"
  - "Therefore I'm still in favour of the module concept for each single device, and think that the front-end guys can bring those things together if they like."
  - "It's the concept of modules what gives FHEM it's flexibility. Why bury that?"
  - "I am against this approach, as it contradicts the idea of modules, which seems to be a success."
  - "... it's just reinventing the wheel"
  - "unknown devices do show up in $GUI; they can be used by sending commands directly"
  - "... there is one idea in it that strikes me as reasonable"
  - "And for front-ends: Even unknown devices are visible, even if not very nicely. And if this really hurts somebody, they know, that they are invited to update every frontend-code to help us."

Arguments in favor:

  - None, really. But at least a different approach was suggested:

    | Because Kai asked for a counter-proposal here is mine:
    |
    | We introduce interfaces ("interface" as "interface in object-oriented programming", not as "interface of a physical device") and enhance the status of the "model" attribute. FS20 and X10 switches implement the "switch" interface, FS20 and X10 dimmers implement a "dimmer" interface, in addition to the "switch interface", weather stations and 1-wire-temperature sensors implement the "thermometer" interface. The consumers of the modules, i.e. the user interfaces, query the interfaces for a device and
decide how to present them to the user, how to order them in rubrics, etc. This would, by the way, also address the calls for a more harmonized naming of readings - a device that implements the "thermometer" interface has a reading named "temperature" as this is part of the interface declaration.



Well, besides myself, there were four other participants until now in roughly
two days' time. Thank you for giving valued input!



*Intermediate personal conclusion*: So, from my point of view, it's ok for the
majority to keep everything the way it is. It's a bit disappointing, but, what
the heck? Obviously I'm trying to solve a non-problem, again
As this basically means, that there is no support intended for new devices in
any UI, unless the one who adopts the modules for FHEM also sends in changes
to any UI author he wants his module supported in as well (as Olaf puts it:
"And if this really hurts somebody, they know, that they are invited to up-
date every frontend-code to help us."), I'll use the time to rewrite my stuff
zu emulate already known devices (which was Plan A anyway ). While loosing
wanted functionality, it's just as they say: a bird in the hand is worth two
in the bush. At least one get's a partial fuction in any FHEM-GUI that way

Off to "Tatort" now,
         kai

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

[Guest]

Originally posted by: <email address deleted>

On 7 Feb., 19:58, "Dr. Boris Neubert" wrote:

> Before I open the "call for interface specs" thread I would like to hear
> opinions from others, both from the module programmers and from the ui
> developers.

As for pgm3: It is possible to include every device (which I know) as
an automatic device or with UserDefs.
The most devices (I think about 95 percent) from the most users like
F20, FHT, KS300, WS300, HMS100, CUL_WS and others are supported
automatically.

However, if there would be something like a new interface or an
additional layer pgm3 would support it. pgm3 gets his information
about xmllist. This means there must be something like a new general
group.

Martin

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

[Dr. Boris Neubert]

                                             

Am 07.02.2010 16:13, schrieb Rudolf Koenig:
>> We introduce interfaces ("interface" as "interface in object-oriented
>> programming", not as "interface of a physical device") [...]
>>    
> But if somebody has the energy to do it, then he should look at the KNX
> definition: AFAIK it has a classification with well defined interfaces. This
> would help to integrate KNX modules / bridges in fhem, and as I was told an
> electrician master has to absolve a KNX course, so talking with them would be
> easier.
>  
can you or anybody recommend a weblink for KNX device
classes/interfaces? The documentation for the KNX standard itself costs
1000 EUR...

Boris

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

[Guest]

Originally posted by: <email address deleted>

Dr. Boris Neubert wrote:

> Am 07.02.2010 18:13, schrieb Kai 'wusel' Siering:
>> So, if I understand you corrently, you're proposing to introduce simply
>> something along these lines?
[...]
>>
> yes, that's it. By virtue of yet-to-be-written specs, a device with
> "dimmer" turning up in $hash->{INTERFACES} is guaranteed to be able to
> be set "on" and "off" and the readings contain something like a status
> reading which is either "on" or off. Or for a device with "thermometer"

Äh, shouldn't be a dimmer also able to do some "dim" commands as well as
on/off? Fortunately, SETs and even GETs are said to retrievable from
the device, so that's a rather nice solution.

> in $hash->{INTERFACES}, there is again, by virtue of the specs, for sure
> a reading "temperature" which contains a floating point number (without
> "°C" or "(Celsius)" or the like). If I am not mistaken all this couldbe
> added without breaking existing user interfaces at all.

Yepp, it can definitively, I'm polluting $hash->{whatever} for quite some
time, no harm done. (Keep in mind that there are T and T/H sensors, "ther-
mometer" doesn't really fit, imho. But for the sake of argument, it's ok )

>> Sens" devices instead. But while you never dreamt of a WS4713, as EnvSens.pm
>> was extended to support it, you instantly know how to handle it as well ...)
>
> In the WS4713 module, just publish the interfaces WS4713 provides and
> you are done. The user interfaces will know what to do.

Sure. But that's what Rudolf said to be unneccessary, so I liked to see
his way to know anything about WSP4713 without the support of the "inter-
faces-proposal". Maybe I'm missing some important point here?

> Extending EnvSens.pm would end up in a monolithic approach with one fat
> module that cannot be maintained any more.  And what about different
> devices with overlapping functionality, e.g. a thermostat? Does such a
> device "inherite" from EnvSens (because it has a temperature reading) or
> from Switch (because it turns things on and off)? There are good reasons
> for multi-class-inheritance not existing in modern programming languages
> in favor of interfaces that can easily circumvent such conflicts in a
> natural way.

Boris, I'm totally aware of the -- nasty -- consequences. But I'm fed up
with writing code for the void I wrote about that earlier; it's no use
for me to do stuff that can't be used by anyone else -- I neither can nor
will update any awesome GUI *in addition* to bringing in a new FHEM device.
So it's either drop back to 2007 and emulate FS20/EM/CUL_WS/... or try to
cure the underlying problem (which obviously is my very own *sigh*).

But, as said before: about the way to solve it, I'm open; but I'm posi-
tive that this should be addressed. I don't *like* the "EnvSens approach"
either. But it would (have) be(en) a really really really quick win
         kai

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

[nobody0472]

                                                                 

HI all,

first of all,
I would like to thank Kai to start this discussion. Althoug being on
"somewhat another side" I like it and I see the need.

So, I try to comment and to argue for what I think is needed and why:
If you google my name, you will figure out, that I'm working in IT-
Research, and especially in user/context-aware platform-systems for
quite some years. Thats a little bit further out, than just home
automation, but it's the same focus. We would like to make life easier
and better for our end-users. And that's the point. It's not about us,
developers.

So, what does this mean for us/home-Automation-guys. ... well:

According to the real industry there (http://de.wikipedia.org/wiki/Geb
%C3%A4udeautomatisierung) (I know, it's not a scientific reference,
but just to make myself more clear):
We have 3 tiers: The Sensor-Tier, the Device/THB tier and the
controller tier.
Beyond that, I also see the Front-End tier as a fourth one.

So, for me: There will ALWAYS be a new sensor every day. And it will
speak always a different protocol, language, whatever. Fine.
On the second tier, we will have always different protocols. I know,
that Tosti (busware) is thinking/dreaming of 6LoWPAN and that's a good
one, but it's far from being there.
So even on the second tier we have many different busses/protocols to
take into account. And for real insdustry there are good field busses,
that we simply haven't touched yet.

So for me FHEM works on the third tier, bringing those things
together. BUT:
We can't ignore, that we have different tier 1/2 systems, therefore we
should also have those different modules in FHEM. Because, if FHEM
expands along all those system (which is my personal goal), we have
thousand s of sensor, and hundreds of protocols to deal with.
Therefore we need those hundresds of modules, dealing with different
protocols, languages and even semantics.

And yes, we need interfaces. But on which level. That's even in
reserach on those topis an open question.

We can argue for environment, we can argue for users behavious, or his
context, or his situation, or whatever.
But what we have so far, are the bus-systems, the interpretations and
therefore the semantics of the different systems that are out there.

And in my opinion, as an open source community, we should use them,
rather than building our own one.
Because in research, there have been hundreds of different trials with
different semantics/modules/interpretations, and all of them have been
overrun by the next generations of modules/interfaces and protocols.
Therefore i would still be in favour of building modules for the
different things/technologies/protocols and build a guidline on
READINGS/SETs/GETs as it is done in object-oriented programming.
Because otherwise there will be the next level of devices running us
over with a completly different structure that can't be integrated in
our complex modules.

And for front-ends .... well
Looking to Web-Services we can observe that Front-End technology is
far beyond sensors/devices/readings. Therefore the Front-End guys
should have maximum freedom to do, whatever they like, and simply use
Sets/Gest to control the other tiers. Because building good frontends
is another kind of research, similar complex to integration of all
these sensors.

So my call is for good interfaces, rather than for complex modules.

A guidline how to build a FHEM-interface with SETs/GETs and GOOD
documentation would be highly appreciated.
And to talk more scientificly ...
based on this SETs/GETs and a good standardized doc I can even build a
UI-compiler that compiles on-the-fly a new UI taking all new modules
into account, if they follow the SETs/GETs syntax and a well
structured doc of semantics. Therfore no recoding on UI-systems would
be needed, just a recompilation, giving the new modules.

Sorry for being so long. But htis is my experience from reserach on
this topic of the last 10 years.

Best,
Olaf



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

[Guest]

Originally posted by: <email address deleted>

Hi,

Olaf wrote:

> automation, but it's the same focus. We would like to make life easier
> and better for our end-users. And that's the point. It's not about us,
> developers.

Agreed.

[...]
> So for me FHEM works on the third tier, bringing those things
> together. BUT:
> We can't ignore, that we have different tier 1/2 systems, therefore we
> should also have those different modules in FHEM. Because, if FHEM
> expands along all those system (which is my personal goal), we have
> thousand s of sensor, and hundreds of protocols to deal with.
> Therefore we need those hundresds of modules, dealing with different
> protocols, languages and even semantics.

I'm absolutely fine with that; but, and I think it's a big "but",
there needs to be something binding this plentora of interfaces
together, on the "telnet side" of FHEM.

[...]
> But what we have so far, are the bus-systems, the interpretations and
> therefore the semantics of the different systems that are out there.
>
> And in my opinion, as an open source community, we should use them,
> rather than building our own one.
> Because in research, there have been hundreds of different trials with
> different semantics/modules/interpretations, and all of them have been
> overrun by the next generations of modules/interfaces and protocols.
> Therefore i would still be in favour of building modules for the
> different things/technologies/protocols and build a guidline on
> READINGS/SETs/GETs as it is done in object-oriented programming.
> Because otherwise there will be the next level of devices running us
> over with a completly different structure that can't be integrated in
> our complex modules.

If I understood that correctly , I still agree; just to be sure: so
you're ok with having the UI issuing a "set PowerSwitch on" for an simple
switch and a "set myPTZCam rotate left 128 tilt 45" to move a Pan-Tilt-
Zoom-Cam "myPTZCam"? Your *not* suggesting that the UI should circum-
vent the FHEM layer of SET/GET/READINGS in any way?

> And for front-ends .... well
> Looking to Web-Services we can observe that Front-End technology is
> far beyond sensors/devices/readings. Therefore the Front-End guys
> should have maximum freedom to do, whatever they like, and simply use
> Sets/Gest to control the other tiers. Because building good frontends
> is another kind of research, similar complex to integration of all
> these sensors.
>
> So my call is for good interfaces, rather than for complex modules.

[Funny, this whole EnvSens stuff went totally different than expected
But I love this thread anyway, as I think it will bring FHEM onwards.]

The reason I went and started this discussion with a rather brute-force
non-solution was that I think there's something missing as of now. FHEM
per se is great stuff. It's approach is open enough for anything I've
thrown at it yet. I can control my TV set via FHEM commands. I can con-
trol power outlets, I can measure energy consumption, I can see the data
my Weather Station provides. AND I can script stuff to be done periodi-
cally or on changed sensor readings.

But here's the but: what FHEM yields in running on it's own, it lacks
in UI support. As of now, any UI needs to be touched for any new type
of device; this is where power turns into weakness in my opinion.

So, I strongly suggest that, while keeping all the flexibility of FHEM,
there should be a framework so one could at least support basic functio-
nality, if a device is similar to one ones code already supports ...

... and I'm really glad that at least Boris ventured a different approach.

> A guidline how to build a FHEM-interface with SETs/GETs and GOOD
> documentation would be highly appreciated.

Ack; but, as pointed out, I think it needs more. For the vast majority
of devices that *can* be categorized or share at least basic functio-
nality, there should be some way for an UI to ask the device what it
supports. Thus, an unknown module is no longer is terra incognita for any
UI, for the benefit of all. (E. g. even my (module for my) TV honours the
basic switch operation: "set 47LG7000 off" turns it off, "set 47LG7000
on" turns it on. Thus, any GUI could support switching it on/off by one
mouseclick. Even without knowing that it's a TV. If only the GUI knew ...)

> And to talk more scientificly ...
> based on this SETs/GETs and a good standardized doc I can even build a
> UI-compiler that compiles on-the-fly a new UI taking all new modules
> into account, if they follow the SETs/GETs syntax and a well
> structured doc of semantics. Therfore no recoding on UI-systems would
> be needed, just a recompilation, giving the new modules.

But that's the point: I do not want the need to recompile an UI. I want
the UI be able to tell a switch apart from a sensor, based on "live" in-
formation from the device in question, not from the author's knowledge
of the FHEM ecosystem at the time of coding. I'm positive that by having
the module tell the UI about what kind of device it is, there IS an ad-
ded benefit without loss of flexibility; the aformentioned PTZ-Cam's
module would just tell nothing or "cam:ptz" if asked for it's "inter-
face". As the UI hasn't heard of "cam" yet, it skips it or displays it
as unknown, that's ok. But for such simple devices as a temperature
sensors, it simply shouldn't matter which module it serves, if an UI
knows how to display "temperature" readings, it should present any
similar device. I don't think there's anything that oppsoses this wish,
even from a scientific point of view?

Thanks to anyone reading up to this
         kai

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

[Guest]

Originally posted by: <email address deleted>

On 08.02.10 01:46, "Kai 'wusel' Siering" wrote:

> So, I strongly suggest that, while keeping all the flexibility of FHEM,
> there should be a framework so one could at least support basic functio-
> nality, if a device is similar to one ones code already supports ...

I'll throw in my 0.02 and vote for 'Interfaces'. Setting up a couple of
interfaces should do the job perfectly for both sides (front/backend).

I still support the idea of 'modules' as this makes it much easier to
differentiate between the devices and makes code more readable. Modules, IMO
should only contain device-specific code and besides that just
'device-definition' (see below).

> Ack; but, as pointed out, I think it needs more. For the vast majority
> of devices that *can* be categorized or share at least basic functio-
> nality, there should be some way for an UI to ask the device what it
> supports. Thus, an unknown module is no longer is terra incognita for any
> UI, for the benefit of all. (E. g. even my (module for my) TV honours the
> basic switch operation: "set 47LG7000 off" turns it off, "set 47LG7000
> on" turns it on. Thus, any GUI could support switching it on/off by one
> mouseclick. Even without knowing that it's a TV. If only the GUI knew ...)

IMHO that's not a good solution,  because it already limits itself in terms
of 'categorization'. The device should NEVER talk to the device, but to the
defined abstraction layer in fhem. IMHO a device should 'report' to FHEM
about it's abilities.
 If a device reports its properties to fhem, fhem already knows how to
handle the device. There's no need for a 'category' at all (beside grouping
devices logically). Furthermore, if a device implements a defined interface
(or even more than one), fhem (as well as any frontend) already knows how to
handle the device. The only specific code inside a module would be the layer
which finally defines the communication to the device.

> But that's the point: I do not want the need to recompile an UI.

Not needed...

> I want
> the UI be able to tell a switch apart from a sensor, based on "live" in-
> formation from the device in question,

Could be done, if the module reports it's devicetype and supports a common
interface.

> not from the author's knowledge
> of the FHEM ecosystem at the time of coding. I'm positive that by having
> the module tell the UI about what kind of device it is, there IS an ad-
> ded benefit without loss of flexibility; the aformentioned PTZ-Cam's
> module would just tell nothing or "cam:ptz" if asked for it's "inter-
> face".

Not good. IMO the cam would return it's properties ( a very simple example
would be : 'live-pict:image', where the first part is the getter, the second
part is the result).

Getting those properties through a getter would be simple as: get('image').

A more complex module would return a set of properties:

{ power:boolean, on-till:datetime, dim:integer... }

> As the UI hasn't heard of "cam" yet, it skips it or displays it
> as unknown, that's ok. But for such simple devices as a temperature
> sensors, it simply shouldn't matter which module it serves, if an UI
> knows how to display "temperature" readings, it should present any
> similar device. I don't think there's anything that oppsoses this wish,
> even from a scientific point of view?

I don't agree to this part of the discussion, as IMHO the functionality
shouldn't be designed after the UI, but the abstract usefulness.

> Thanks to anyone reading up to this

You're welcome

a.


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