Re: Re:Predictive failures

On 4/16/2024 10:25 AM, Edward Rawde wrote:

Better to inform the individual who can get the replacement done when the
tenant isn't even home.

>
So, a WiFi/BT link to <whatever>?  Now the simple smoke detector starts
suffering from feeping creaturism.  "Download the app..."

 No thanks. I have the same view of cameras.
They won't be connecting outbound to a server anywhere in the world.
But the average user does not know that and just wants the pictures on their
phone.

There is no need for a manufacturer to interpose themselves in such
"remote access".  Having the device register with a DDNS service
cuts out the need for the manufacturer to essentially provide THAT
service.
OTOH, the manufacturer wants to "keep selling toilet paper" and
has used that business model to underwrite the cost of the "device".
Everything, here, is wired.  And, my designs have the same approach:
partly because I can distribute power over the fabric; partly because
it removes an attqck surface (RF jamming); partly for reliability
(no reliance on services that the user doesn't "own"); partly for
privacy (no information leaking -- even by side channel inference).
My wireless connections are all short range and of necessity
(e.g., the car connects via wifi so the views from the external
cameras can be viewed on it's LCD screen as it pulls out/in).

Give that to some software which also knows how long the equipment has
been
in use, how often
it has been used, what the temperature and humidity was, how long it's
been
since the oil was changed,
and you might be able to give the operator useful information about when
to
schedule specific maintenance.

>
I have all of those things -- with the exception of knowing which sensory
data
is most pertinent to failure prediction.

 That's one reason why you want feedback from people who use your equipment.

All they know is when something BREAKS.  But, my device also knows that
(unless EVERY "thing" breaks at the same time).  The devices can capture
pertinent data to adjust it's model of when those other devices are
likely to suffer similar failures because the failed device shared
its observations with them (via a common knowledge base).

OTOH, if there is no oil in the gearbox, the equipment isn't going to
start; if the oil sensor is defective, then *it* needs to be replaced.

 Preferably by me purchasing a new sensor and being able to replace it
myself.

If it makes sense to do so.  Replacing a temperature sensor inside an
MCU is likely not cost effective, something folks are capable of doing nor
supported as an FRU.