[FHZ] Introducing EnvSens & Call for Discussion

[nobody0472]

                                                                 

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.

[Guest]

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.

[Guest]

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.

[Dr. Boris Neubert]

                                             

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.