Re: Dealing with "past" events

Don Y <blockedofcourse@foo.invalid> wrote:

On 11/24/2024 12:50 PM, Don Y wrote:

I should have been clearer.  The "home automation system" consisted
of devices (which ATM are of no interest) and user interface/scheduler
working as a normal application on standard OS.  User interface
was supposed to be easy but allows users to define various
actions.  The point is that in making it "easy" (and probably
simple to implement) user interface got crippled so that resonable
thing was hard to do.

 
That's an opportunity for a supplier to offer an "assistant"
(if they don't control the actual system) to assist the user.
Eventually, the original developer will come to realize
THEY should offer the assistant's functionality in the base
product.  But, that only needs to be at some level of
abstraction between the user and the hardware.  It need not
be part of the OS itself (even if the user THINKS of it as
part of the "OS")

 
I.e., the "original system" offers the mechanisms (to talk to the
various "devices") but the policy about how to use those mechanisms
is embodied in the "assistant".
 
[Of course, if the system is (completely) closed, then the user is stuck
with whatever assumptions the developer baked into the application]

AFAIK the system was open-source, so theoreticaly third parties could
add any improvements they wished.  But it seems that original
developer considered UI as major added-value and there were no
official/documented way to decouple UI from other parts (there were
documented way to add new devices).

There is also question of project dynamics, there are competing
projects and this one probably did not attract much interest
among outside developers.  And of course software evolves,
so this could be solved in the future.

--
                              Waldek Hebisch