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.
> [...] 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.
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.
> >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.
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.
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.
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.
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.
> 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.
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.
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.
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][/size]
[size=+2]You don't need to "know" FS20 or X10 or Pw_Cirle anymore:
[/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.
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][/size]
>
> [size=+2]You don't need to "know" FS20 or X10 or Pw_Cirle
> anymore:
> [/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.
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.
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.
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.
> 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.
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.
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.
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.
> 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
HI again,
so you are looking for the same thing, as researchers in middleware-
systems (or SoA in the new age) are looking for the last 10 years.
A common ontology/semantic (beyond just syntax and interfaces) to
figure out what a system (or service in new age) can do, without
apriori knowledge.
As everybody has a different understanding of what EnvSens should be
(just an example) or what 'User Context' could be, there won't be an
automated way to do this in general.
And as FHEM reaches already far beyond "just" sensing with common
sensors, the scope is already to broad to have a common/agreeable
semantic.
As research (especially SoA) has told us, there won't be a unique
Ontology/semantic, therefore SoA (for example) is still working on
simple strings and common OO-Interfaces are reduced to SET/GET
functions.
I fully understand your aim, but there can't be a general solution as
the scope is too broad already. And as everyday new devices/sensors
are popping up (which is good) it will be even harder to have it in
the future. Therefore I like to approach of automated recompilation of
front-ends to take all new things into account.
Otherwise you are running service/device/semantic-discoveries and
trying to match meanings and interfaces.
This leads to, what research denotes as the feature-interaction
problem.
Best,
Olaf
On 8 Feb., 01:46, "Kai 'wusel' Siering"
wrote:
> 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.
Originally posted by: <email address deleted>
Hi,
as I was answering on Andy and Olaf, that mail went too long,
again. So, while I value your input, the answers might be terse,
please don't take that as an offense.
Ah, and as a foreword:
If you're thinking still in EnvSens terms, drop that. EnvSens has had
it's purpose, in that it proves that different but similar devices can
be handled by one set of controls. Going that monotithic path is a bad
idea, as has been pointed out already; I'm fine with that.
Please let's focus on the path Boris suggested: »We introduce inter-
faces ("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" in-
terface, FS20 and X10 dimmers implement a "dimmer" interface, in
addition to the "switch interface", weather stations and 1-wire-tem-
perature 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.«
Andy Fuchs wrote:
>> 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
Hm. I need to rephrase this, it should read: "For the vast majority of
devices that *can* be categorized or share at least basic functionality,
there should be some way for an UI to *get the information of what the*
device supports."
> 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.
Ack. That's what I _meant_ but didn't actually _write_ unambiguously, sorry.
> 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.
That's not true. The frontend does know nothing about the device Foo.Bar
of type WSP4714 -- besides that there is a device known as Foo.Bar to fhem.pl,
it's status is "ok", it's IODev is known to fhem.pl as FooBarDev ... As it
seems it can query the GETs and SETs available. How does frontend present
Foo.Bar? How does frontend tell apart a Geiger counter from an VCR or a
switch for the room lights? If that would be possible, the whole discussion
would be moot; but no-one has pointed a way to that yet.
>> But that's the point: I do not want the need to recompile an UI.
>
> Not needed...
Not only needed, it's mandatory today with FHEM.
>> Thanks to anyone reading up to this ;)
>
> You're welcome :-)
Thanks ;)
Olaf wrote:
> I fully understand your aim, but there can't be a general solution as
> the scope is too broad already. And as everyday new devices/sensors
> are popping up (which is good) it will be even harder to have it in
> the future. Therefore I like to approach of automated recompilation of
> front-ends to take all new things into account.
>
> Otherwise you are running service/device/semantic-discoveries and
> trying to match meanings and interfaces.
> This leads to, what research denotes as the feature-interaction
> problem.
I don't intend to save the world or academical problems; I simply ask
for a way *not* needing to extend each and any frontend to support a
device that it basically already supports, with same interface, only
with a different naming/"low-level driver".
But "hinting an UI on which of the predefined interfaces is supported
by a device, so that an UI can make most use of it even without know-
ing all the details" can't be that much of a problem. It's not about
defining today how the interface "car" needs to be.
It's not even anything new. *Any* frontend dealing today with an FS20-ST
already programmatically "knows" how to deal with a "model" "FS20-ST" of
"TYPE" "FS20". Same applies to X10 I suppose ... And the interface bet-
ween frontend and fhem.pl for on/off is the same as well for FS20 & X10,
see commandref.html.
Thus, what needs to done is: defining in the FHEM guidlines that the
"interface" "switch" means "device can be set on or off". After that,
any frontend *can* make use of this definition *and* the "interfaces"
value provided. So, even "model" "FS30-S" of "TYPE" "FS30" with "inter-
face" "switch" could be handled by a frontend that never even heard of
FS30. Not to it's full potential, maybe, but at least it's known that
it's a user-switchable device ...
To switch contexts: I can connect a SIXAXIS controller to my Linux box
and it is "recognised" as a joystick. The SIXAXIS can do more than just
plain joystick, but's it's what the (Linux) system and the (SIXAXIS)
hardware have in common. If you want more, you need to go beyond this
basic interface: "The Linux joystick interface (joydev.ko, /dev/input/js*)
does not report inertial measurements from the accelerometers and gyro.
The hidraw interface can be used instead. It transfers raw HID input
reports to user-space and works identically in USB mode and in
Bluetooth mode."
So, I don't need a SIXAXIS driver for basic operation. Why should I need
a special driver for my FHEM-UI for just-another-bloody-thermometer that
delivers "temperature" in READINGS as any already supported one does? ;)
Still puzzled,
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.
Originally posted by: <email address deleted>
On 08.02.10 16:59, "Kai 'wusel' Siering" wrote:
>> 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.
>
> That's not true. The frontend does know nothing about the device Foo.Bar
> of type WSP4714 -- besides that there is a device known as Foo.Bar to fhem.pl,
> it's status is "ok", it's IODev is known to fhem.pl as FooBarDev ... As it
> seems it can query the GETs and SETs available. How does frontend present
> Foo.Bar? How does frontend tell apart a Geiger counter from an VCR or a
> switch for the room lights? If that would be possible, the whole discussion
> would be moot; but no-one has pointed a way to that yet.
There are a couple of ways to accomplish this. None of the ways I have in
mind, needs the ability to talk to the device directly. The device reports
its abilities to FHEM -> the UI queries FHEM for the details.
In your example, the device can be handled by fhem (fhem got this
information through the device's properties and getters).
The UI will get the information on what's being handled by fhem. THIS is the
information the UI wants. There's no point for the UI to show other
information which can NOT be handled by FHEM (besides for statistical
purposes)...
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.
Kai 'wusel' Siering schrieb:
> Dr. Boris Neubert wrote:
>
>> 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.
yes, I was yet somewhat confused at the time of writing. A dimmer device
should support the switch and the dimmer interfaces.
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.