4 ms·
Cause that's probably outside the scope of the request tht was given. This is absoultely speculation, but my guess would be that the way this product came to l
by csydas 10y ago
Cause that's probably outside the scope of the request tht was given.
This is absoultely speculation, but my guess would be that the way this product came to life is as follows:
1. Company saw a niche for IoT products with pet owners willing to splurge on their pets (an aside, pets owners are very happy to spend...)
2. Requested IoT software for already existing auto-feeders to be written up as fast as possible
3. IoT part written and works, product is rushed out without designing an offline mode (either not interested or to be patched later) [1]
It was an imagined race to be first with the product and get the pet feeder IoT device on the market first and build up a brand name. The end result is this silliness.
Basically, I don't think they envisioned an issue where the servers would go down - if the customer's own net went down, obviously they're to blame for Sharik and Musya not being fed.
I sure this sounds overly cynnical, but as was mentioned by someone else, this is just the first of many such things to come with shoddy IoT devices. The practical consideration of "well, what if the servers go down?" just doesn't seem to be on people's minds with IoT.
[1] From their twitter, I was right - they didn't bother with an offline sync in the firmware, and had to build it out: https://twitter.com/petnetiosupport/status/758380813759033344 https://twitter.com/petnetiosupport/status/75838081375903334...