Re: Dealing with "past" events

On 11/24/2024 2:26 PM, Waldek Hebisch wrote:

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

Obviously (?) the primary developer(s) had a different priority
than BEING open source.  I.e., they still wanted control over
the project/product and thought keeping parts of it "closed"
(effectively) gave them that.

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.

I take a different approach.  I'm not interested in "controlling"
a project -- any more than I am interested in babysitting
someone's children!
Nor am I particularly interested in "making money"; I've done enough
of that in my career to be "comfortable" (and have no one who depends
upon me for some "inheritance").  Having "customers" is like having
hemorrhoids!
Rather, I want to see my designs USED -- even if they are transformed
or repurposed in the process.
I've chosen to tackle a few problems that I (personally) consider as
important in my prototype:
- addressing users with varying "disabilities" (to be non-politically correct)
   instead of unilaterally relying on sight and mobility
- addressing users who might otherwise "need" to move into "assisted
   living" facilities simply because they don't have the time or
   faculties to remember all the "little things" that are important
   if you continue to occupy your home
[E.g., You left something on the stove.  The toilet mechanism is leaking;
call a plumber.  The garage door is still open, an hour after you've returned
home.  The freezer is no longer maintaining the desired temperature, your
foods are likely going to spoil.  The roses need to be watered.  The "emitter"
for the citrus trees appears to be clogged as water isn't flowing thru it
at the rate it should be.  You are *lying* on the bathroom floor.  You need
to purchase more coffee beans.  You've been going to the bathroom excessively; perhaps you need to consult a doctor?  You forgot to take your medications.
The wheelchair needs to be recharged.  etc.]