3 ms·

Note that certification could also include verifying there is a plan in place for whatever period of support is reasonable. (We could dig deeper on this.) Con

Note that certification could also include verifying there is a plan in place for whatever period of support is reasonable. (We could dig deeper on this.) Configuration options are hard to support. Say for example a "power level" setting is exposed (how much power is consumed to provide the device functionality). But it is also the case that more power shortens the lifespan of the device. A general client can end up setting that to 100% but won't know about the consequent lifespan issues, or too low a level results in half the functionality being switched off. By robustness I don't mean malformed inputs etc, but rather what is done with valid values. A general client will be oblivious, but an in house could present only part of the power range (the rest behind an "advanced" section). Settings will also interact with each other in device specific ways (eg power would affect maximum volume for an audio device). Pretty soon you'll need a complicated highly featured description language for the settings, interactions, cautions, effects etc. Also would you want to take support calls if external tools have been modifying the configuration, given that a single support call costs the same or more than the profit on the device? That all said, I see nothing wrong with someone publishing and maintaining a set of best practises. IMHO it is the route most likely to get traction and improvement in devices.

kbenson 10y ago
I think any certification that requires a plan be in place for future support is going to be either too weak (if the company goes under, support is gone) or too burdensome (requiring some trust be in place for future support should the company go under is very inefficient). Just allow more control by the user. This lowers barriers to entry for the market, and allows for interesting and unique future uses. As for non-standard methods of configuration and support, I see no problem with requiring your own software if you want it to be supported, and requiring it be set to default levels (or a verification that no values are outside norms) before a support incident is allowed. You want to permanently log whether any settings have been set that void your warranty? Go ahead. This is a solved problem. Try to get Apple to fix your phone if the little water sensor inside has been tripped. I see no problem certifying hardware, I'm just not sure how something like UL for software works in practice.
- rogerbinns 10y ago
  We likely have different ideas of what constitutes future support. You seem to want the A+ package. I think it is sufficient that consumers get a pro-rated amount of their money back, depending on time since purchase. That can be done similar to insurance or escrow. (Although that is still a form a trust for future support.) If you buy something for $100 and 24 months later they pull service, should you get back $10 or $100? Only the smaller end seems viable to me. > Just allow more control by the user Given infinite people, time and money that is easy. I can't see any way of it being practical though. It is considerably more engineering effort, considerably more support effort (all that stuff has to be documented, tested and revised), will increase time to market etc. The only winners are those folks still using the device when service is pulled! I'm sceptical that generic third party configuration could be reasonably done well. Is there any example of something similar? SNMP was mentioned as a failure by another commenter. Certifying the software could be done like some other certification is done: * Publish the list of best practises (eg authentication, update mechanisms, how they participate in the network, long term service) * Have auditors (yeah they would need to be certified too) that will come in and examine a product/code base/service and give their blessing for relevant best practises. I'd imagine some open source libraries would end up certified too (eg an updater, or authentication) so a quicker path to product certification would be use already certified components. * Award the certification based on auditor report Yes it could be gamed, there would be wiggle room, bad actors etc. But it would be a lot better than we have now, and a feedback loop would help improve. BTW I am working on a product somewhat in the space. I'd love to make it completely open, available for ever, plugin your own servers etc. But it isn't remotely viable for people, time and money reasons.
  - armistace 10y ago
    I am not by any means an engineer so you can most definitely take what I say with a grain of salt. But my understanding is that all that really needs to happen for IoT devices to be usable by a third party is for the manufacturer to simply publish the API and provide a mechanism for the end user to control what interfaces with the API. It doesn't actually require you to standardise the API as you have never guaranteed compatibility with any third party it simply requires documentation, which would have to already exist internally for development purposes, and on some level some loss of control. But surely, this way you then get to maintain control and development for as long as you want to support it and for those people that then want to support it themselves after you have abandoned it can as API is a known entity. I am probably fundamentally misunderstanding an aspect of the development of this somewhere but this does not seem that burdensome to me I don't even see the necessity of a standard that needs maintaining here just documentation of the API and a mechanism to change where the data is sent. Hell if you want to maintain control for the life of the device fine, but what is so hard about releasing that information when you no longer want anything to do with it, what possible commercial value does that information hold then?

kbenson 10y ago

I think any certification that requires a plan be in place for future support is going to be either too weak (if the company goes under, support is gone) or too burdensome (requiring some trust be in place for future support should the company go under is very inefficient). Just allow more control by the user. This lowers barriers to entry for the market, and allows for interesting and unique future uses. As for non-standard methods of configuration and support, I see no problem with requiring your own software if you want it to be supported, and requiring it be set to default levels (or a verification that no values are outside norms) before a support incident is allowed. You want to permanently log whether any settings have been set that void your warranty? Go ahead. This is a solved problem. Try to get Apple to fix your phone if the little water sensor inside has been tripped. I see no problem certifying hardware, I'm just not sure how something like UL for software works in practice.

rogerbinns 10y ago
We likely have different ideas of what constitutes future support. You seem to want the A+ package. I think it is sufficient that consumers get a pro-rated amount of their money back, depending on time since purchase. That can be done similar to insurance or escrow. (Although that is still a form a trust for future support.) If you buy something for $100 and 24 months later they pull service, should you get back $10 or $100? Only the smaller end seems viable to me. > Just allow more control by the user Given infinite people, time and money that is easy. I can't see any way of it being practical though. It is considerably more engineering effort, considerably more support effort (all that stuff has to be documented, tested and revised), will increase time to market etc. The only winners are those folks still using the device when service is pulled! I'm sceptical that generic third party configuration could be reasonably done well. Is there any example of something similar? SNMP was mentioned as a failure by another commenter. Certifying the software could be done like some other certification is done: * Publish the list of best practises (eg authentication, update mechanisms, how they participate in the network, long term service) * Have auditors (yeah they would need to be certified too) that will come in and examine a product/code base/service and give their blessing for relevant best practises. I'd imagine some open source libraries would end up certified too (eg an updater, or authentication) so a quicker path to product certification would be use already certified components. * Award the certification based on auditor report Yes it could be gamed, there would be wiggle room, bad actors etc. But it would be a lot better than we have now, and a feedback loop would help improve. BTW I am working on a product somewhat in the space. I'd love to make it completely open, available for ever, plugin your own servers etc. But it isn't remotely viable for people, time and money reasons.
- armistace 10y ago
  I am not by any means an engineer so you can most definitely take what I say with a grain of salt. But my understanding is that all that really needs to happen for IoT devices to be usable by a third party is for the manufacturer to simply publish the API and provide a mechanism for the end user to control what interfaces with the API. It doesn't actually require you to standardise the API as you have never guaranteed compatibility with any third party it simply requires documentation, which would have to already exist internally for development purposes, and on some level some loss of control. But surely, this way you then get to maintain control and development for as long as you want to support it and for those people that then want to support it themselves after you have abandoned it can as API is a known entity. I am probably fundamentally misunderstanding an aspect of the development of this somewhere but this does not seem that burdensome to me I don't even see the necessity of a standard that needs maintaining here just documentation of the API and a mechanism to change where the data is sent. Hell if you want to maintain control for the life of the device fine, but what is so hard about releasing that information when you no longer want anything to do with it, what possible commercial value does that information hold then?