[FHZ] Introducing EnvSens & Call for Discussion

[Guest]

Originally posted by: <email address deleted>

As mentioned on another, german language, thread, I pondered about dropping
the "this hardware has this logical FHEM device" for at least for most of the
temperature/humidity, or more generally "environmental conditions", sensors.
This includes devices previously handled by CUL_WS, WS3600 and CUL_FHTTK for
now (as I'm using them, so I could test directly); I'd like to extend this
to HMS100TF and HMS100TFK as well, maybe FS20TFK (I don't own one), maybe others.

Reason for this: S300TH, HMS100TF and even weather stations usually operate
similar: they just send in environmental data ... But if we're having own
FHEM modules for each, functionally similar, device, frontends get much more
complicated that neccessary. So, by directing all of them to one module, which
should level the differences as much as possible but retain useful differen-
ciators at the same time, presenting the data and using the devices, in my
opinion, should be easier and more straight forward.

So, hopefully starting a lively discussion , here's a first glance of the
outcome (pgm2-screenshot attached, some "list" info below). It would be some
sort of major surgery to switch to EnvSens, as with EnvSens in place, CUL_WS,
CUL_FHTTK, WS3600 (as of now) will vanish (code was moved to EnvSens.pm), thus
I'm not updating CVS for the time being. (Well, I could upload EnvSens.pm for
testing; you'd need to modify CUL.pm to use it with S300TH & FHT80TF yourself
then.)

Comments?
         kai

P.S.: Yes, EnvSens does feature autocreate, of course That's where those WS3600
       names come from; for the _TH and Fenster_ devices I just changes the define
       line to use EnvSens instead of the former ones.




fhem> list EnvSens_WS3600_DP
Internals:
    CODE       WS_WS3600_DP
    DEF        WS_WS3600_DP
    LASTIODev  WS3600
    MSGCNT     10
    NAME       EnvSens_WS3600_DP
    NR         133
    SENSTYPE   WSx
    STATE      1.6
    TYPE       EnvSens
    WS3600_MSGCNT 10
    WS3600_TIME 2010-02-05 11:47:43
    Readings:
      2010-02-05 11:47:43   DEVFAMILY       WS3600
      2010-02-05 11:47:43   DEVTYPE         temp
      2010-02-05 11:47:43   temperature     1.6
Attributes:
    room       EnvSens

fhem> list Bad_TH
Internals:
    CODE       7
    CUL_MSGCNT 1
    CUL_RAWMSG K61080240E3
    CUL_RSSI   -88.5
    CUL_TIME   2010-02-05 11:41:22
    CUN_MSGCNT 2
    CUN_RAWMSG K6107024005
    CUN_RSSI   -71.5
    CUN_TIME   2010-02-05 11:47:10
    DEF        7
    LASTIODev  CUN
    MSGCNT     3
    NAME       Bad_TH
    NR         35
    SENSTYPE   WS
    STATE      T: 20.7  H: 40
    TYPE       EnvSens
    corr1      0
    corr2      0
    corr3      0
    corr4      0
    Readings:
      2010-02-05 11:47:10   DEVFAMILY       WS300
      2010-02-05 11:47:10   DEVTYPE         S300TH
      2010-02-05 11:47:10   humidity        40
      2010-02-05 11:47:10   state           T: 20.7  H: 40
      2010-02-05 11:47:10   temperature     20.7
Attributes:
    room       Bad

fhem> list EnvSens_WS3600_To
Internals:
    CODE       WS_WS3600_To
    DEF        WS_WS3600_To
    LASTIODev  WS3600
    MSGCNT     11
    NAME       EnvSens_WS3600_To
    NR         131
    SENSTYPE   WSx
    STATE      4.0
    TYPE       EnvSens
    WS3600_MSGCNT 11
    WS3600_TIME 2010-02-05 11:48:55
    Readings:
      2010-02-05 11:48:55   DEVFAMILY       WS3600
      2010-02-05 11:48:55   DEVTYPE         temp
      2010-02-05 11:48:55   temperature     4.0
Attributes:
    room       EnvSens

fhem> list EnvSens_WS3600_RP
Internals:
    CODE       WS_WS3600_RP
    DEF        WS_WS3600_RP
    LASTIODev  WS3600
    MSGCNT     11
    NAME       EnvSens_WS3600_RP
    NR         143
    SENSTYPE   WSx
    STATE      994.400
    TYPE       EnvSens
    WS3600_MSGCNT 11
    WS3600_TIME 2010-02-05 11:48:55
    Readings:
      2010-02-05 11:48:55   DEVFAMILY       WS3600
      2010-02-05 11:48:55   DEVTYPE         pressure
      2010-02-05 11:48:55   pressure        994.400
Attributes:
    room       EnvSens

fhem> list Fenster_Arbeit
Internals:
    CODE       FHTTF_124ab2
    DEF        FHTTF_124ab2
    NAME       Fenster_Arbeit
    NR         19
    OPEN       1
    PREVSTATE  Open
    PREVTIMESTAMP 1265366653
    SENSTYPE   FHTTF
    STATE      Open
    TYPE       EnvSens
    Prev:
      STATE      01
      TIMESTAMP  1265366905
    Readings:
      2010-02-05 11:48:25   Battery         ok
      2010-02-05 11:48:25   Contact         Open
      2010-02-05 11:35:33   DEVFAMILY       FHT80TF
      2010-02-05 11:35:33   DEVTYPE         contact
      2010-02-05 11:48:25   Reliability     ok
Attributes:
    room       Arbeit

--
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]

                                                   

> [...] as with EnvSens in place, CUL_WS, CUL_FHTTK, WS3600 (as of now) will
> vanish (code was moved to EnvSens.pm)

Kai, could you please clarify how EnvSens is working?  As far as I understand
it now, you merge the code from the above mentioned modules into one. This
somehow contradicts my idea of modules...

I do not even understand (yet why using a single module should be an
advantage for frontends.

--
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:
>> [...] as with EnvSens in place, CUL_WS, CUL_FHTTK, WS3600 (as of now) will
>> vanish (code was moved to EnvSens.pm)
>
> Kai, could you please clarify how EnvSens is working?  As far as I understand
> it now, you merge the code from the above mentioned modules into one. This
> somehow contradicts my idea of modules...

Yes, and no

Yes, if you think about complexity within a single module: as
EnvSens not supports one but many lower level moduls, if you
have changes in one of them, you need to adapt EnvSens.pm as
well. Same goes for debugging, maybe. If you look at code size
and memory footprint when using only one type of the EnvSens-
supported sensors, then yes, the bigger EnvSens module is not
as effective as e. g. CUL_FHTTK.pm alone (if only CUL_FHTTK,
no CUL_EM, ... is used).

BUT ... On the other hand, as of now, the user needs to consider
what kind of sensor is used and get's temperature readings e. g.
for the bathroom (S300TH) from CUL_EM, for the living room from
FHT and for the basement from HMS. Even if autocreate is used, he
(or she ) get's in the config file:

define HMS_07bf HMS 07bf
define CUL_EM_1 CUL_EM 1
define FHT_3e06 FHT 3e06

I _think_ that this outcome of the modularity issue is more a draw-
back for the user when he tries to understand what's going on and
how things are supposed to work (it was at least for me).
And _I_ think that this approach, always having a "hardware" module
that feeds input into a "logical" module to parse and present the
data from that hardware, traces back to the very beginning of FHEM,
where there basically were no functional overlappings of the "logi-
cal" modules.
But this is neither the case anymore nor is there a need for it, nor
is it that useful anymore (at least in my opinion ).

The basic idea is already set into code in current FHEM: reuse code
and interfaces if possible, think e. g. of the "backend" CUL.pm
which reformats messages received into the "wire format" they'd
have of received via FHZ.pm and therefore dropping the need for
duplicate code and additional API, regardless of the underlying
reception hardware. Similar stuff happens for CUL_EM vs. KS300.

By EnvSens, I basically broaden this, actually _making use of_
the modularity as given and intended: You define your hardwares,
e. g. FHZ, CUL, maybe a USB connected Weatherstation, a JeeNode
receiving IT+ sensors, whatever. BUT, instead of sending temp-
erature/humidity/wind/etc. sensor data to a (maybe) hardware-
dependend module, it is simply fed into one module interpreting
and presenting _those_ data: EnvSens. (See bottom of post for
an outlook into the future.)

The advantage I see is a reduced complexity at the surface: The
User needs to know about one device, EnvSens, for all his envi-
ronmental readings.
Any (G)UI only needs to know about this _one_ module (and which data
it gets in which format) for temp/humidity/wind/etc., so even future
additions to what EnvSens.pm can handle should have no impact on
a GUI already written: the new data will show up and can be used
immediately, without the need to update the UI as well.

This is fundamentaly different to now, where there *is* no standard
whatsover for logical devices of any kind. Each UI needs to know
about every logical module in question to be able to parse that
data. This, by the way, is also my answer to ...

> I do not even understand (yet why using a single module should be an
> advantage for frontends.

... that question. I haven't looked into the code of any UI for FHEM
yet; but from what I know of the command set of FHEM, if I'd want to
write a UI myself, I see currently *no alternative* than to do a
"module" that handles CUL_WS devices, one that takes care of WS300,
one of KS300, one that parses HMS, ... for providing just the info
regarding temperature/humidity/and so on. (See pgm2 with CUL_EM, HMS
and maybe an attached weather station as an example.)

This changes, drastically -- and in my opinion, beatyfully -- with
EnvSens. Now I *know* that "any supported sensor for temperature/hu-
midity/wind/rain/... is taken care of by the EnvSens module". (It will,
as soon as FHT & HMS environmental data is parsed there as well, in
which case EnvSens most likely will be just a "parasitic consumer" of
the data, which is possible [1].)
EnvSens shall adhere to strict(er) standards (HMS: "temperature 20.8
(Celsius)", FHT: "measured-temp 23.9 (Celsius)", CUL_EM: "temperature
23.3"), which should be more easy to uphold in one module than in do-
zens of them.
Whether stuff like the TFK-devices ("Tür-Fenster-Kontakt", door or
window contacs actually fit into the "Environmental Sensor" umbrella:
I don't know yet. But given that there are at least three types cur-
rently already supported (in HMS, FS20 and CUL_FHTTK/indirectly via
FHT), one should think about "unifying" their handling as well.


So, to put it in a (large) nutshell, the BENEFITS:

The BENEFIT for any (G)UI: temperature/humidity/and so on would be
now handled by EnvSens (using DEVFAMILY & DEVTYPE to further describe
the sensor; but all temperature (if any) is given in $def->{READINGS}\
{temperature}{VAL}, all humidity data in ...{humidity}{VAL} and so on,
regardless of the source). If someone adds new hardware support to
FHEM that reads temperature/humidity/..., instead of rolling his own
module, he/she just add's the parsing code to EnvSens.pm *AND THE NEW
HARDWARE INSTANTLY WORKS WITH EVERY UI* already switched to EnvSens.

The BENEFIT for any user of FHEM: reduced complexity, no more handling
with CUL_EM, HMS, ... but only one module that takes care of utilizing
those sensors. (A lessened PITA [2] since autocreate, but I still find
it rather confusing with all theese modules, some operating identically.)
In conjunction with the UI argument, he also get's a more straight
forward user experience, as all this temperature/... readings may be in
one place (pgm2: EnvSens, instead of CUL_EM, FHT, HMS, ...).

The BENEFIT for anyone adding stuff to FHEM: one point where to add
the ParsFN() stuff for the new hardware (in terms of temp/hum/...).
It could further be the central point in FHEM to do unit conversions
(°C <=> K <=> °F, ...). Going this route, the new data will be avail-
able to any UI/frontend already using EnvSens. Having only one module
to check "how did they do that?" further reduces the chance of differ-
ing outputs.


DRAWBACKS: The biggest problem I can see right now are multiple-use
devices like, e. g. the FHT, where one most likely would not like
EnvSens to "consume" the temperature readings. This has to be taken
care of via [1]. Furthermore, if one adds a similar device, that is
one that rectifies a separate module (like FHT, which is a controlling
device, not just a temperature sensor), he SHOULD add any environmen-
tal part to EnvSens as well, duplication work. And, last but not least,
the EnvSens.pm will keep getting bigger and bigger, and since using
perl, most likely difficult to maintain over time.


Outlook, beyond EnvSens:

For general purpose stuff like switches, on/off resp. open/closed sen-
sors, "weather/environment data" (temp/hum/...) I dare to have a way
to unify access for the UIs. I think this is rather important, if FHEM
shall be considered a still worked-on framework and be "competitative"
in the home automation area. Initially, I pondered whether to implement
SIS_PMS by "going the CUL-way": faking FS20 messages and using the al-
ready existing FS20 module to represent switchable sockets ... I didn't
to that, simply because FS20 lacks the bi-directional component SIS_PMS
features. But this OTOH means: no UI on this planet currently displays
SIS_PMS devices in a useful way -- DESPITE switching of power sockets
is already implemented ...
Think of a FS20 successor, FSng, that can easily be adopted to FHEM due
to an open API (yepp, I'm daydreaming ) but uses bi-directional com-
munications, so it's possible to actually CHECK the switches' status.
Will this become 00_FSng.pm (talking to the IF) and 14_FSng.pm (for the
logical devices) or would you fake FSng messages to look as FS20 ones
and have FS20 take over?

So, yes: after merging "environmental stuff" into EnvSens, I would go
and join FS20 (switching part), X10 (switching part; is there a sensor
component?), SIS_PMS and Plugwise (switching part) into 42_Actors.pm
or something. Some goes for EMEM, EMWZ, Plugwise (measurement part) into,
say, 42_EnergySens.pm.

Instead of anyone rolling his or her own module, I strongly suggest to
define a framework module for each of, at least, environmental condi-
tions (temp/hum/wind/rain/...), controlling actors (FS20, X10, ...) and
energy measurement (ELV's EM system, Plugwise, future stuff?) -- NOW

This takes the modularity FHEM provides, in my opinion, to a better use
than just having two dozens of modules just because of ... we, well,
modularize.


I do assume that there might be other ways to achive a similar goal,
that is to unify access to certain data, but this would most likely
involve more than "just" exchanging one module for another.

Regards,
         kai


[1] FHEM list, thread "Eigene Module":

| > Kann es auch mehrere MatchFn/ParseFn-Kombies für eine Physischen
| > Nachricht geben ?
|
| Ja. Falls das ParseFn eines Moduls "undef" zurueckliefert, dann wird nach dem
| naechsten Modul gesucht.

[2] http://www.urbandictionary.com/define.php?term=PITA

--
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]

                                                   

> >Kai, could you please clarify how EnvSens is working?
[...]

Kai, you answered here lot of questions,  but not the above one.  Let's try
with a more concrete one: Is EnvSens using the data from the unique modules
like FS20/FHT/etc or directly from CUL.pm?

--
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:
>>> Kai, could you please clarify how EnvSens is working?
> [...]
>
> Kai, you answered here lot of questions,  but not the above one.  Let's try
> with a more concrete one: Is EnvSens using the data from the unique modules
> like FS20/FHT/etc or directly from CUL.pm?

Maybe ...

| By EnvSens, I basically broaden this, actually _making use of_
| the modularity as given and intended: You define your hardwares,
| e. g. FHZ, CUL, maybe a USB connected Weatherstation, a JeeNode
| receiving IT+ sensors, whatever. BUT, instead of sending temp-
| erature/humidity/wind/etc. sensor data to a (maybe) hardware-
| dependend module, it is simply fed into one module interpreting
| and presenting _those_ data: EnvSens. (See bottom of post for
| an outlook into the future.)

... wasn't clear enough, so:

- EnvSens is called instead of CUL_EM.
- EnvSens is called from WS3600 (which previously did not interface outsite of itself).
- EnvSens is called instead of CUL_FHTTK.
- EnvSens is called from digitemp.pm (focusing on 1-Wire temp sensors for now)
- HMS/FHT has not yet been touched; for them, it will be called most
   likely additionally to HMS & FHT, as EnvSens will only take care of a
   subset of HMS devices (HMS100TF, HMS100TFK if CUL_FHTTK merges into
   EnvSens) or a subset of the data (measured-temp of an FHT) respectively.
- I would change the code of WS2000, WS300 to call EnvSens' ParseFN instead of
   parsing directly, but need someone for testing the result. Same goes for KS300:
   As soon as there's someone willing to test with KS300 (can't, as I have none),
   I'd adopt that as well.

Or, more technically for 00_CUL.pm:

--- /home/wusel/fhem-20100122/FHEM/00_CUL.pm    2009-12-21 19:03:56.000000000 +0100
+++ 00_CUL.pm   2010-02-06 18:46:23.000000000 +0100
@@ -55,16 +55,16 @@
    $hash->{ReadFn}  = "CUL_Read";
    $hash->{WriteFn} = "CUL_Write";
    $hash->{Clients} =
-        ":FS20:FHT:KS300:CUL_EM:CUL_WS:USF1000:HMS:CUL_FHTTK:CUL_RFR:FHT8V:";
+        ":FS20:FHT:KS300:CUL_EM:EnvSens:USF1000:HMS:CUL_RFR:FHT8V:";
    my %mc = (
      "1:USF1000"   => "^81..(04|0c)..0101a001a5ceaa00....",
      "2:FS20"      => "^81..(04|0c)..0101a001",
      "3:FHT"       => "^81..(04|09|0d)..(0909a001|83098301|c409c401)..",
      "4:KS300"     => "^810d04..4027a001",
-    "5:CUL_WS"    => "^K.....",
+    "5:EnvSens"   => "^K.....",
      "6:CUL_EM"    => "^E0.................\$",
      "7:HMS"       => "^810e04....(1|5|9).a001",
-    "8:CUL_FHTTK" => "^T........",
+    "8:EnvSens"   => "^T........",
      "9:CUL_RFR"   => "^[0-9A-F]{4}U.",
    );
    $hash->{MatchList} = \%mc;

The goal is to reduce the number of logical modules, streamlining the
interface levels while retaining the underlying functionality.
         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>

Rudolf Koenig wrote:
>>> Kai, could you please clarify how EnvSens is working?
> [...]
>
> Kai, you answered here lot of questions,  but not the above one.  Let's try
> with a more concrete one: Is EnvSens using the data from the unique modules
> like FS20/FHT/etc or directly from CUL.pm?

Now, having answered that question, the counter-question Is there a way to
hook into the unique modules (FS20/FHT/whatever)? From my understanding, there's
only the possibility to put a match into %mc in the receiving module before the
original one and returning not undef, if the data was consumed, undef, if it's
to be presented to other modules down the line, correct?
         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>

Hallo Kai,

jetzt muss ich doch mal direkt fragen....

Heißt dass jetzt du passt alle Module im CVS nach deinen Wünschen an ?
Das liest sich hier so als ob du mit der Axt durchs CVS fährts....

Wenn du alle Sensoren in ein Modul packst...brauchst du doch z.B. an
CUL_Ws garnichts zu ändern.
Wenn dein EnvSens alles händelt, kannst du z.B. CUL_WS  aus deinem
Modul-Verzeichnis  doch einfach löschen und gut ist.

-    "5:CUL_WS"    => "^K.....",
+    "5:EnvSens"   => "^K.....",
Gilt für die anderen Module dann nat. auch....

Den Ansatz alles in ein Modul zu packen finde ich nicht gut.....
Ich glaube nicht der Anwender will alle Sensordaten "auf einmal"
sehen...
Was bringt ihm das ??
Ob da jetzt eine Tabelle mit Temparatur oder zwei Tabellen
stehen...ist doch egal..

Wenn dir eine "Meta-Schicht" fehlt.....
Ich hätte gerne eine Sicht auf mein Haus....
So in etwa:
MeinGrundstueck.MeinHaus.Erdgeschoss.Wohnzimmer.Temperatur
MeinGrundstueck.MeinHaus.Erdgeschoss.Wohnzimmer.Humidity
MeinGrundstueck.MeinHaus.Erdgeschoss.Wohnzimmer.Actuator
MeinGrundstueck.MeinHaus.Erdgeschoss.Wohnzimmer.Window
MeinGrundstueck.MeinGartenTemperatur

Wer die einzelnen Werte liefert ist mir bei der Sicht "wurscht" )


Schöne Grüße

Axel

--
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>

Axel wrote:

> jetzt muss ich doch mal direkt fragen....
>
> Heißt dass jetzt du passt alle Module im CVS nach deinen Wünschen an ?

Nein. Ich habe einen Proof of Concept gebaut, darin habe ich zwei
eigene und zwei bestehende Module zu einem neuen verheiratet. In-
wiefern das sinnvoll ist oder nicht, das ist der Teil

         *& Call for Discussion*

im Subject.

_Ich_ halte es für notwendig, daß -- wie, da bin ich vollkommen er-
gebnisoffen, nur bei daß bin ich relativ fix -- FHEM eine tiefer-
greifende, vorauswirkende Struktur bekommt. Das mit 247 Modulen für
alles und jedes ist nett; siehe aber z. B. den "set on-for-timer
added for X10 modules"-Thread, wenn alles und jedes immer anders
funktioniert und Neues erst mühsam in andere, auf FHEM aufbauende
Module eingepflegt werden muß, wird "man" daran mit der Zeit die
Lust verlieren

> Das liest sich hier so als ob du mit der Axt durchs CVS fährts....

Naja, noch fahre ich mit der Axt durch mein /usr/local/lib/FHEM. Zum
CVS war ich eher eindeutig, oder? "It would be some sort of major
surgery to switch to EnvSens, as with EnvSens in place, CUL_WS, CUL_-
FHTTK, WS3600 (as of now) will vanish (code was moved to EnvSens.pm),
thus I'm not updating CVS for the time being."

[...]
> Ich glaube nicht der Anwender will alle Sensordaten "auf einmal"
> sehen...
> Was bringt ihm das ??
> Ob da jetzt eine Tabelle mit Temparatur oder zwei Tabellen
> stehen...ist doch egal..

Jein; ob/wie er das auf der Präsentationsschicht haben möchte, ist mir
mehr so egal. Es geht mir darum, daß der derzeitige Ansatz im Backend
für zukünftige Erweiterungen in der Unterstützung der Frontends zu kurz
greift. Es gibt keine Vorsorge seitens FHEM dafür, daß funktional ähn-
liche oder gar identische Geräte auch von älteren Frontends erkannt
und behandelt werden können -- trotz i. d. R. sogar nahezu bis identi-
schem Befehlssatz.

> Wenn dir eine "Meta-Schicht" fehlt.....

Genau. Die fehlt mir, aber nicht im Frontend ...

> Ich hätte gerne eine Sicht auf mein Haus....

... sondern in FHEM als Backend. Wegen dem Bild und den 1000 Worten,
ein Screenshot von myHCE 0.9.2 vs. "FHEM-pgm2-per-CVS". Dazu ist an-
zumerken, daß myHCE 0.9.2 sich nur um FS20 & FHT gekümmert hat, aber
das Beispiel funktioniert dennoch:

Gäbe es eine "Meta-Schicht" "Schaltaktoren" (statt FS20, X10, ...)
und wären sowohl die von SIS_PMS als auch Pw_Circle gesteuerten Steck-
dosen dort mit drin, könnte myHCE 0.9.2 schon damit umgehen (Status
anzeigen, Schalten), *obwohl* es das Modul zum Entstehungszeitpunkt
des Frontends "myHCE" noch gar nicht gab. So kennt myHCE nur FS20-
Schalter; wäre FHEM seinerzeit schon "meta-isiert" gewesen, wäre die
Situation eine andere -- und die Nützlichkeit ggf. höher. Natürlich
könnte myHCE 0.9.2 von den Pw_Circle-Geräten keine Verbrauchsdaten
auslesen -- aber myHCE 0.9.2 könnte mit "set device off"/"set device
on" diese Schalter trotzdem schon steuern.

myHCE ist nur ein Beispiel; da niemand weiß, welche Module für FHEM
in 3 Monaten existieren, kann niemand irgendwo Vorsorge treffen, diese
zu untersützten, es muß immer nachgearbeitet werden. EnvSens ist diese
"Meta-Schicht" als *Proof-of-Concept* und Diskussionsgrundlage.

> Wer die einzelnen Werte liefert ist mir bei der Sicht "wurscht" )

RRRRRRRRÜCHTÜCHHHH! Das ist der Punkt. Das kann auf Abstraktionsebene
FHEM auch den Frontends egal sein und sollte es auch. Ich möchte die
Temperatur des Heizkessels und des Warmwassertanks und die Vorlauf-
temperatur, die Außentemperatur und die Temperatur im Wohnzimmer "haben".
Daß dahinter mal 1-Wire, mal 'n RS232-Interface, mal ein FHT und mal
eine Wetterstation steckt -- who cares? Das sind doch Details, die FHEM
für mich verbergen bzw. korrekt behandeln sollte -- und das *kann* FHEM
sogar vorzüglich. Nur wird's derzeit nicht genutzt, weil es keine "Ge-
räteklassen" gibt. (FHT80B ist da als programmierter Aktor ein Sonder-
fall; aber als Thermometer ist er so gut oder so schlecht wie alles an-
dere.)

Ich möchte, daß, wenn jemand ein neues Modul für FHEM baut, dieses
möglichst ohne Änderungen an bestehender Software auch genutzt werden
kann. Dies ist heute nicht gewährleistet. EnvSens ist dazu ein, *mein*
*Vorschlag*, dieses Problem -- ich finde, es ist eins -- zu adres-
sieren.
Er ist radikal, ja; und sonst? Zerreist ihn in der Luft -- solange da
konstruktive Vorschläge kommen, ist das ok Auch die Meinung "Löt-
zinn das alles; FHEM steht für FS20-Steuerung, das kann es, das soll
es, alles andere ist mehr als flüssig" würde ich gerne hören, wenn sie
jemand hätte. (X10 und HS485 immerhin liegt ja schon jemandem am Her-
zen )

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.

[rudolfkoenig]

                                                   

> The goal is to reduce the number of logical modules, streamlining the
> interface levels while retaining the underlying functionality.

I am against this approach, as it contradicts the idea of modules, which seems
to be a success. Right now nobody dares to touch fhem.pl itself but writing a
module for a given device seems to be no problem for a lot of people.

I think EnvSense is just reinventing the wheel: soon calls for modularizing
EnvSense will come, and then we have the same situation like today, with an
added level of hierarchy/complexity.

At least pgm2 supports new devices, even without a uniform interface. Maybe a
different color for the new type is missing (it is on my TODO list to remove
this silly feature), and perhaps switching on/off is not on the summary page
for a new type.  But if "set ?" is working as expected, pgm2 will
make all set commands available, and putting on/off to the front page could be
generalized too.


> Is there a way to hook into the unique modules (FS20/FHT/whatever)?

Not really. A module could accept messages before another one (see below), and
call the ParseFn of the other one for certain message types.


> From my understanding, there's only the possibility to put a match into %mc
> in the receiving module before the original one and returning not undef, if
> the data was consumed, undef, if it's to be presented to other modules down
> the line, correct?

Yes, and the order in the %mc structure is relevant for undefined devices and
autoloading.  The similar feature for defined devices is the ORDER which is
stored in the filename: When both 10_FS20.pm and 88_EnvSense.pm accept a given
message, then 10_FS20.pm wins. I have to rename 88_EnvSense.pm to
09_EnvSense.pm in order to be used instead of 10_FS20.pm.  This is how USF1000
works.

--
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>

Hallo Kai,

die Diskussion hier gehört in den "FHEM Standard"-Thread....
http://groups.google.com/group/fhem-users/browse_thread/thread/7c650c75d97606bd

Gerade das Modul-Konzept macht FHEM doch so flexibel....
Und das willst du gerade aushebeln...

>Gäbe es eine "Meta-Schicht" "Schaltaktoren" (statt FS20, X10, ...)
>und wären sowohl die von SIS_PMS als auch Pw_Circle
:READINGS
$defs{}{READINGS}{VAL} -> Messdaten vom Device u.a. Switch:On/
Off,Temperature,WindowOpen
$defs{}{READINGS}{TIME} -> Zeitstempel
$defs{}{READINGS}{UNIT} -> Einheit °C, rel% etc.
$defs{}{READINGS}{HISTORY}
dann hier noch
$defs{}{READINGS}{STYPE} -> SensorType z.B.
Dimmer,Schalter,EnvData ....

Dann ist doch alles an Infos vorhanden...
Das UI kann das dann "Zusammenbauen" ...

> Das ist der Punkt. Das kann auf Abstraktionsebene
> FHEM auch den Frontends egal sein und sollte es auch

nö...
fhem.pl liefert die Daten und stellt sie allen anderen zur
Verfügung...
Die Daten werden auf Basis von Hardware geliefert...die ist nun mal
unterschiedlich...
"Meta-Schichten/Ansichten" und so'n Zeuch ist UI Aufgabe...
Bsp.:
FielSysteme für Linux...
Da würdest du doch auch nicht vorschlagen, die FileSystem-Treiber in
eine Datei zu packen...
Da willst du doch "nur" das Ergebnis:
mount -t fhem.fs /dev/user/kai /fhem/modul_mensch/
cd /fhem/modul_mensch/
ls
Sensor  Augen
Sensor  Nase
Sensor  Hand

und ls ist UI )))

Schöne Grüße

Axel

--
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]

                                             

Rudolf Koenig schrieb:
>> The goal is to reduce the number of logical modules, streamlining the
>> interface levels while retaining the underlying functionality.
>>    
> I am against this approach, as it contradicts the idea of modules, which seems
> to be a success. Right now nobody dares to touch fhem.pl itself but writing a
> module for a given device seems to be no problem for a lot of people.
>
>  
although the objective of the EnvSens module is still not yet totally
clear to me there is one idea in it that strikes me as reasonable. It
was the hint to the discussion about dim and bright commands in FS20 and
X10 that rung the bell and reminded me of a similar conversation with
Martin Haas in the context of the ordering of X10 and FS20 switching
devices and S555TH and HMS100TH temperature/humidity devices into
rubrics in pgm3.

Kai's proposal points toward a hardware/protocol abstraction layer, i.e.
devices with identical function get presented via the same API. First it
must be totally clear that such an abstraction layer does in no way mean
that one needs lesser efforts for integrating a new module in fhem - the
device/protocol-specific code has to be written and this is encapsulated
in what is called a module. No reason to merge several modules into one
bigger one.

The question is more how to access the module's readings in a more
standardized/harmonized way. As the hardware is different the modules
should be separated and it is against the paradigm of
object-orientation, taking it for granted that it applies here, to merge
modules for different devices into one. Having thrown in the term
object-orientation, the question is whether the objects (modules) should
not present a standardized interfaces to the caller!

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.

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>

Rudolf Koenig wrote:

>> The goal is to reduce the number of logical modules, streamlining the
>> interface levels while retaining the underlying functionality.
>
> I am against this approach,

Understood, as well as expected

> writing a
> module for a given device seems to be no problem for a lot of people.

Sure. It's not that there is a problem *writing* a module for a hardware
with the current approach. Using it even works -- on the raw interface
of FHEM, if the user know's about the new device.

> I think EnvSense is just reinventing the wheel:

In a sense, yes; it is basically just a "cat {this,and,that}.pm >EnvSens.pm".
The added benefit is, that it's, for the first time, *defining* a class
of devices it supports and handles, first by it's $hash->{TYPE} (as set by
fhem.pl}, second by extending CUL_WS' device classification by setting
$hash->{READINGS}{DEVTYPE} and $hash->{READINGS}{DEVFAMILY}.

> At least pgm2 supports new devices, even without a uniform interface. Maybe a
> different color for the new type is missing (it is on my TODO list to remove
> this silly feature), and perhaps switching on/off is not on the summary page
> for a new type.

Neither is the status icon as even pgm2 simply does not *know* anything
about this MyDevice. The EnvSens approach just cures that, once and for
all

> But if "set ?" is working as expected, pgm2 will make all set
> commands available, and putting on/off to the front page could be
> generalized too.

Yeah, that's really working great (even if a bit underdocumented *hint* ),
having the device tell the frontend what SETs it supports.

And it's what EnvSens does on device level: it "tells" anyone using it what
kind of devices it supports, which READINGS to expect and which basic function.
So, just like ?detail=DEVICE in pgm2 "magically" knowns what can be SET, by
adopting EnvSens, pgm2 would "know" how to handle *any* future device of this
kind. It could handle it coherently, like it does with FS20 devices already
(which is because of the extensive coding based on $hash->{ATTR}{TYPE}, not
my magic, of course).

If there *would* *be* a defined way of classifing a device, there would be no
need for EnvSens. As the "understanding" of what kind of device is supported
by a given $hash->{TYPE}-device is *only* based on that value, norming THAT
name is the way to go I'm proposing.

Or, in marketing terms:

[size=+1]You "know" what to do with $hash->{TYPE} eq "FS20" but you don't with
$hash->{TYPE} eq "Pw_Circle"?[/size]

[size=+10]Well, fear no more![/size]

[size=+2]You don't need to "know" FS20 or X10 or Pw_Cirle anymore:
SwitchingActors.pm andles this all for you[/size]



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>

Hi all,

as being one of the "front-end" writers, and being an installer for
different users, I'm totally in favour of the module concept.

You can use modules, as needed, and can leave them out, if not.

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

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.

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.

And as we are talking about software, things will change over time
anyway, therefore adaptation is needed from time to time.

I don't like to put all the things in one module. Just to give a short
reason:

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.

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

Just my 2 cents.

Olaf


Kai 'wusel' Siering schrieb:
> Rudolf Koenig wrote:
>
>>> The goal is to reduce the number of logical modules, streamlining the
>>> interface levels while retaining the underlying functionality.
>>
>> I am against this approach,
>
> Understood, as well as expected
>
>> writing a
>> module for a given device seems to be no problem for a lot of people.
>
> Sure. It's not that there is a problem *writing* a module for a hardware
> with the current approach. Using it even works -- on the raw interface
> of FHEM, if the user know's about the new device.
>
>> I think EnvSense is just reinventing the wheel:
>
> In a sense, yes; it is basically just a "cat {this,and,that}.pm
>  >EnvSens.pm".
> The added benefit is, that it's, for the first time, *defining* a class
> of devices it supports and handles, first by it's $hash->{TYPE} (as set by
> fhem.pl}, second by extending CUL_WS' device classification by setting
> $hash->{READINGS}{DEVTYPE} and $hash->{READINGS}{DEVFAMILY}.
>
>> At least pgm2 supports new devices, even without a uniform interface.
>> Maybe a
>> different color for the new type is missing (it is on my TODO list to
>> remove
>> this silly feature), and perhaps switching on/off is not on the
>> summary page
>> for a new type.
>
> Neither is the status icon as even pgm2 simply does not *know* anything
> about this MyDevice. The EnvSens approach just cures that, once and for
> all
>
>> But if "set ?" is working as expected, pgm2 will make all
>> set
>> commands available, and putting on/off to the front page could be
>> generalized too.
>
> Yeah, that's really working great (even if a bit underdocumented *hint*
> ),
> having the device tell the frontend what SETs it supports.
>
> And it's what EnvSens does on device level: it "tells" anyone using it what
> kind of devices it supports, which READINGS to expect and which basic
> function.
> So, just like ?detail=DEVICE in pgm2 "magically" knowns what can be SET, by
> adopting EnvSens, pgm2 would "know" how to handle *any* future device of
> this
> kind. It could handle it coherently, like it does with FS20 devices already
> (which is because of the extensive coding based on $hash->{ATTR}{TYPE}, not
> my magic, of course).
>
> If there *would* *be* a defined way of classifing a device, there would
> be no
> need for EnvSens. As the "understanding" of what kind of device is
> supported
> by a given $hash->{TYPE}-device is *only* based on that value, norming THAT
> name is the way to go I'm proposing.
>
> Or, in marketing terms:
>
> [size=+1]You "know" what to do with $hash->{TYPE} eq "FS20" but
> you don't with
> $hash->{TYPE} eq "Pw_Circle"?[/size]
>
> [size=+10]Well, fear no more![/size]
>
> [size=+2]You don't need to "know" FS20 or X10 or Pw_Cirle
> anymore:
> SwitchingActors.pm andles this all for you[/size]
>
>
>
> Ciao,
>             kai
>

--
------------------------------------------------------------------------
Dr. Olaf Droegehorn
General Manager              Tel.  : +49-561-82020-410
DHS - Computertechnik GmbH   Fax.  : +49-561-82020-399
Carlsdorfer Straße 3         E-Mail: O.Droegehorn@dhs-computertechnik.de

                              WEB:    www.dhs-computertechnik.de
D-34128 Kassel
------------------------------------------------------------------------

--
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>

Axel wrote:

> die Diskussion hier gehört in den "FHEM Standard"-Thread....
> http://groups.google.com/group/fhem-users/browse_thread/thread/7c650c75d97606bd

Nein, da es über die Standardisierung bestehender Werte hinausgeht: es
geht um nicht weniger als die programmtechnisch Standardisierung, nein,
*Klassifizierung* der Geräte, die die Module behandeln. Das ist etwas,
was es bislang schlechterdings nicht gibt.

Ich möchte, daß "man", d. h. ein Programm bzw. dessen Herr und Meister,
erkennen kann, um was für eine grobe Art von Gerät es sich handelt und
entsprechend Vorbereitungen treffen.

Ja, es gibt das TYPE-Attribut. Es ist weder verpflichtend (ich möchte
"leider" hinzufügen), modulübergreifend noch ausreichend für das, was
ich suche. Wer sich die Mühe gemacht hat, die EnvSens-Ausgaben sich an-
zusehen, der wird feststellen, daß EnvSens bestimmte READINGS setzt
(übernommen & erweitert aus CUL_WS; und ja, ob das nach READINGS oder
eher nach ATTR oder gar PROPERTIES gehört, *die Diskussion* gehörte
dann in den Standards-Thread), die das fragliche Gerät näher spezifi-
zieren.
Basierend auf b) "EnvSens-Geräte sind Sensoren für Umgebungswerte" und
b) "EnvSens nutzt (dies & das) zur näheren Klassifizierung" kann jeder
jedes EnvSens-Gerät grundlegend, Stand heute sogar vollumfänglich, be-
dienen, lies: Code für ein Frontend dafür schreiben.

Das *IST* ein Fortschritt gegenüber heute, denn mit meinem HomeMatic®.pm
bringe ich zwar HomeMatic®-Geräte nach FHEM -- bedienen kann ich sie mit
bestehenden Frontends aber nicht, denn kein Frontend kennt HomeMatic®-
Geräte oder das HomeMatic®-Modul.

> Gerade das Modul-Konzept macht FHEM doch so flexibel....
> Und das willst du gerade aushebeln...

Nein. Ich will es nur *richtig* nutzbar machen. Und der einzige Weg, das
in endlicher Zeit zu bewirken, ist, das exponentielle Wachstum der Modul-
anzahl *heute* einzufangen und durch generischere Module zu ersetzen --
oder gibt es einen anderen?

>> Gäbe es eine "Meta-Schicht" "Schaltaktoren" (statt FS20, X10, ...)
>> und wären sowohl die von SIS_PMS als auch Pw_Circle
> :READINGS
> $defs{}{READINGS}{VAL} -> Messdaten vom Device u.a. Switch:On/
> Off,Temperature,WindowOpen
> $defs{}{READINGS}{TIME} -> Zeitstempel
> $defs{}{READINGS}{UNIT} -> Einheit °C, rel% etc.
> $defs{}{READINGS}{HISTORY}
> dann hier noch
> $defs{}{READINGS}{STYPE} -> SensorType z.B.
> Dimmer,Schalter,EnvData ....
>
> Dann ist doch alles an Infos vorhanden...

Yepp, "dann". Also nicht jetzt. Wenn darüber Konsens herschen würde, daß
sowas richtig, wichtig oder notwendig wäre, wäre man einen Schritt weiter.

Siehe CUL_WS/EnvSens-LISTs, da ist das exemplarisch umgesetzt; nur so wie
eine DefineFN() verpflichtend ist (AFAIK), so müßte auch das setzen dieser
Werte verpflichtend sein (lies: auch von fhem.pl forciert werden), sonst
ist nix gewonnen.

>> Das ist der Punkt. Das kann auf Abstraktionsebene
>> FHEM auch den Frontends egal sein und sollte es auch
>
> nö...
> fhem.pl liefert die Daten und stellt sie allen anderen zur
> Verfügung...
> Die Daten werden auf Basis von Hardware geliefert...die ist nun mal
> unterschiedlich...

Muß sie nicht. Nicht oberhalb FHEM. Da hat sie es auch nicht mehr ...
Wenn ich Spaß mit Hardware haben will, bitbange ich sie direkt. Der
Mehrwert einer Schicht wie FHEM ist grade die Abstraktion von der Hard-
ware. Das wird vorzüglich umgesetzt in Teilaspekten von pgm2 -- pgm2
kann sowohl SIS_PMS als auch Pw_Circle schalten, obwohl pgm2 noch nie
was davon gehört hat -- und ist generell in FHEM durch die normierte
Schnittstelle (GET, SET, ATTR) umgesetzt.

Was aber fehlt ist der Blick über den FS20-Tellerrand. Kann pgm2 z. B.
vom Zielmodul abfragen, welche Parameter denn SETzbar sind (wie geht
das eigentlich?), gibt es diese Möglichkeit (meines Wissens) für GET
nicht.
Gar nicht vorgesehen ist es auch, eine Unterscheidung zu treffen, ob
das Gerät read-only, write-only, read-write ist (inwiefern das wich-
tig ist, vermag ich aktuell nicht zu beurteilen) und welcher *Art*
das Gerät ist, also z. B. ein Aktor (dann funktioniert in aller Regel
ja "set on" & "set device off", bei Dimmern vielleicht auch
ein Dimm-Befehl) oder ein Sensor oder wasauchimmer.
Diese Entscheidung ist derzeit eine 1:1 Abbildung auf den Modulnamen,
... ich wiederhole mich

> "Meta-Schichten/Ansichten" und so'n Zeuch ist UI Aufgabe...

Nope. Die Information, daß es ein FS20-Gerät, konkret ein Dimmer,
ist, benötigt die UI, da FHEM hier bisher nichts normiert hat. (Ok,
das stimmt nicht ganz; was SETzbar ist, scheint (zumindest für pgm2)
abfragbar zu sein; wenn daraus ein normierter FHEM-Befehssatz würde,
wäre schon einiges gewonnen.)
Der UI hat es egal zu sein, wie der Befehl zum Gerät kommt -- und ist
es ja auch, denn die UI wird nur "set myFS20Dimmer dim87%" absetzen,
nicht hingegen das System nach einem CUL oder einer FHZ absuchen und
diese direkt ansprechen.

Daraus folgt: FHEM *ist* die Metaschicht, die Schicht zwischen Hard-
ware und Oberfläche.

> Bsp.:
> FielSysteme für Linux...
> Da würdest du doch auch nicht vorschlagen, die FileSystem-Treiber in
> eine Datei zu packen...
> Da willst du doch "nur" das Ergebnis:
> mount -t fhem.fs /dev/user/kai /fhem/modul_mensch/
> cd /fhem/modul_mensch/
> ls
> Sensor  Augen
> Sensor  Nase
> Sensor  Hand
>
> und ls ist UI )))

Nicht alles, was hinkt, ist ein Vergleich Ich schlage konkret *nicht*
vor, 00_FHZ.pm und 00_CUL.pm in eine Datei zu packen, korrekt. Ich schlage
aber schon vor, daß wir endlich ein fhem.fs bauen, damit man /dev/user/kai
genauso wie /dev/user/Axel nutzen kann. Bisher geht nämlich nur

mount -t fhem-kai.fs  /dev/user/kai  /fhem/modul_mensch/kai
cd /fhem/modul_mensch/kai
ls
ls: cannot access .: Unknown format
ls-kai
Sensor  Augen
Sensor  Nase
Sensor  Hand
mount -t fhem-Axel.fs /dev/user/Axel /fhem/modul_mensch/Axel
cd /fhem/modul_mensch/Axel
ls
ls: cannot access .: Unknown format
ls-Axel
sensor  AUGEN
sensor  NASE
sensor  HAND

Findest Du das zielführend? Ich nicht
         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:

> Rudolf Koenig schrieb:
>>> The goal is to reduce the number of logical modules, streamlining the
>>> interface levels while retaining the underlying functionality.
>>>    
>> I am against this approach, as it contradicts the idea of modules,
[...]

> although the objective of the EnvSens module is still not yet totally
> clear to me there is one idea in it that strikes me as reasonable. It
> was the hint to the discussion about dim and bright commands in FS20 and
> X10 that rung the bell and reminded me of a similar conversation with
> Martin Haas in the context of the ordering of X10 and FS20 switching
> devices and S555TH and HMS100TH temperature/humidity devices into
> rubrics in pgm3.

And it won't stop there. There's already OWTEMP with similar deliverables
as S300TH/HMS200TF/HMS100T as well as WS2000, WS300, WS3600, ... There
is EMEM and Pw_Circle for energy measurement at plug/socket level. There
is FS20-ST and Pw_Circle and, maybe, even KIKU/Intertechno-433-Plugs for
switching loads.

> Kai's proposal points toward a hardware/protocol abstraction layer, i.e.
> devices with identical function get presented via the same API. First it

s/identical/similar/ as identical would not yield much. Identical func-
tion is already taken care of (in each module); it's classifying similar
devices as being similar devices that share a similar basic way of oper-
ation what I'm after.

> must be totally clear that such an abstraction layer does in no way mean
> that one needs lesser efforts for integrating a new module in fhem - the
> device/protocol-specific code has to be written and this is encapsulated
> in what is called a module. No reason to merge several modules into one
> bigger one.

Merging the handling of all similar devices into one appropriately named
"bigger one" would instantly yield the classification -- which today is
based solely on the module's name. That's why I tried this with some sen-
sors I use myself and *it works beautifully*. It's a PITA in other areas,
of course

> The question is more how to access the module's readings in a more
> standardized/harmonized way. As the hardware is different the modules
> should be separated and it is against the paradigm of
> object-orientation, taking it for granted that it applies here, to merge
> modules for different devices into one. Having thrown in the term
> object-orientation, the question is whether the objects (modules) should
> not present a standardized interfaces to the caller!

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.

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
be replaced by hardware-orientation. EnvSens conseqently addresses this,
in current FHEM's diction, and replaces half a dozen of hardwares by
nice little objects of type EnvSens. It's actually rather simple

> 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.

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.

Are there other voices, arguments, thoughts?

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.