Hacker News new | comments | show | ask | jobs | submit login

I currently working in foodservice equipment, and I'll concur with this.

The problem with IoT isn't the backend. There are plenty of companies that figured out the servers, ingestion, security, dashboarding, etc.

The problem is all the nodes. Customers aren't going to replace equipment with newer systems just because it has IoT capabilities, which means you're attempting to retrofit machinery with sensors and connectivity. Or else you wait until the major chain customer has refreshed every single piece of equipment in every store. Set your calendar for 7-10 years and check back in.

For retrofitting, every single case is different, it's custom, and 90% of the time it's not easy. And, no, slapping a Raspberry Pi to the side of a milkshake freezer isn't the answer. Some products like Helium are closer, but an array of open-collector GPIOs isn't the answer either.

The only way to win here is to be highly vertical and close to your customers not only in business knowledge but actual integration with the equipment makers. I certainly don't see GE, MS, AWS, Google or anyone else really making the commitment to that kind of stuff.




I cannot see any IoT revolution. Let's globally forget about the consumer market, already dead, but focus on the industrial applications.

Going from $10 to $1 a sensor didn't trigger any change. Not surprising when yearly maintenance/battery replacement/shipping/installation/network fee is circa $50/y per sensor and this economics didn't change. Big data didn't change anything, as the cost of storing info was already peanuts before.


There are plenty of sensor without batteries, using e.g. light or vibration to get their energy, of which they need very little...


You still need local collection hubs and network infrastructure to get the data out. The cost of the sensor isn't the issue.


>> For retrofitting, every single case is different, it's custom, and 90% of the time it's not easy. And, no, slapping a Raspberry Pi to the side of a milkshake freezer isn't the answer. Some products like Helium are closer, but an array of open-collector GPIOs isn't the answer either.

>> 90% of the time it's not easy

Why ?

And maybe the right approach is a marketplace approach ?

Say i'm an someone who have created a node for fridge X, at my local town. allow me to upload designs of hardware(or maybe standard programmable hw, what makes sense), software, cables, documentation, maybe verification - and to sell them to anybody, easily.

And when someone orders such designs, the marketplace sends him everything fully working with simple installation instructions ?


That will work for some of it.

Quite a bit of industrial stuff is one offs, were you have the only one(s) in existence. I've made devices for industrial use were the customer only needed 1-5 of them.


Exactly. If you've never debugged code with a logic analyzer, you can't understand what a hellacious bespoke PITA embedded realtime software can be. Personally, I like this stuff, but it's not everybody's cup of tea, and while your experience is transferable to the next problem, your work product often is not.


It's also not usually running on state-of-the-art chips and architectures. Think about hooking into a 8051 microcontroller (circa 1989) with on-chip RAM and EEPROM and no spare I/O.


For those types of devices, do you think a board built around something like a PSOC chip(fully programmable analog+digital+mcu chip) or something improved along those lines, give enough programmability to cover plenty of such devices and help implementers ?


The hardware might be fine. With the software, it's already harder, it needs adaptation, if not writing from scratch. With sensors, it's fitting them to the unique mechanical circumstances of the one-off machine. And both if these you can't scale, can't reuse.


For that specific customer, off the self stuff would not last more than a day or two as it had to survive -20C to 80C temperature swings in the space of a few minutes, along with the enclosure being rated to IP69K. The single board computer we used was off the shelf, then modified to survive the conditions inside the enclosure (eg: adding conformal coatings).

Making electronics survive those conditions is expensive and most people don't need that level of protection.


A PSoC-focused design trades flexibility for price, power, and performance. Hard sell.


I have this feeling you're used to an open ecosystem (like web design) where everyone shares code and designs somewhat freely.

In my line of work, that's the complete opposite of what goes on. Ecosystems are closed for a number of reasons including patents, warranty, and liability.

Unless you work directly with the equipment maker and their circle of suppliers and customers, getting full approval along the way from every party (including the end customer who has no idea what's inside that black box), you're pretty much going to be on the outside.


>> Unless you work directly with the equipment maker and their circle of suppliers and customers

What does this mean ? being a certified field engineer, with the explicit permission of IOT retrofitting ? And if so why ?

And assuming the equipment manufacturer is interested in a way of doing this, wouldn't he be interested in scaling and maybe some profit and other benefits(we'll probably find some benefits along the way) ?


Companies that manufacture and sell industrial equipment shy away from any third-party modifications or additions to their units.

First off, it will invalidate the warranty and cause many headaches for service personnel. Customers depend on that warranty and service network and many times it's part of the purchase contract.

Secondly, a lot of equipment is validated and approved by the customer before installation. For example, any piece of kitchen equipment that goes into a McDonald's has been validated and tested in their corporate kitchens before it's even allowed to approach an actual store. Modifications and retrofits are, again, not allowed without their permission. So unless you have a business relationship with McDonald's beforehand, you won't get the time of day from them.

Thirdly, there's no profit motive in it for the manufacturer. I've worked on systems where IoT subsystems can help with predictive maintenance (thereby minimizing emergency service calls and expensive downtime), but the cost of that system typically isn't passed on to the final customer price.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: