Only if the IoT product developers want it to work, would be my answer. This quote kind of says it all:
"Home automation is almost a dirty word among some technophiles because it's been tried and tried again and hasn't taken off."
I would say "home integration" rather than "home automation." I have PLENTY of automated appliances in my home already, including a fancy new toaster oven, but I have no need or inclination to integrate them. Even creating an IoT, for some of these home appliances, does not necessarily mean that there's any need to integrate among them.
This discussion is somewhat related to the one about automobile hacking. Next thing you know, we'll see a frenzy about the potential security holes that COULD emerge in homes, IF your kitchen faucet is tied to your washer, drier, and power meter.
Although parenthetically, it might make sense to tie your cold water kitchen faucet to the garbage disposer, to prevent the latter from being switched on in the former isn't open. Whether the Internet and your Facebook page need to know about this is something else again.
It could be useful if used in a two-stage development. Initial prototype implementation is done using the libraries. Then, following market validation that there is a significant market, start stage 2 - code, resource, cost, performance optimized implementation.
The catch is not getting caught up in release/update cycle, and allocating sufficient time and resources for State 2 development.
The small startup like WigWag already has a team in Wuxi, China, and the software runs on Allwinner's chip, aside from that of Freescale, speaks volume for the anticipated IoT pickup in the Chinese market.
Seems its a prerequisite nowadays for a chip company of any size to have team in China.
I thought it was an interesting design win for Allwinner. My perception of that company is that it makes relatively inexpensive apps processors for tablets, but it seems as though there is more to it than that.
@mcgrathdylan, Allwinner is by far the number one tablet apps processor company in China. The company has big ambitions. Obviously, Allwinner wants to get into the smartphone business (and automotive). But it is interesting to learn that it appears to keep an eye on IOT.
More on Allwinner, please go to the following link. It's based on my visit to the company located in Zhuhai.
As we are moving to a world where just about everything can have an IP address and be connected by TCP-IP, I see all sorts of potential beyond the stated use case here.
Part of the problem with the IoT is the wide variety of protocols, like 6LowPAN, CoAP, DASH7, EnOcean, Insteon, Zigbee, and Z-Wave mentioned in the article. Any grouping of IoT devices will likely be heterogenous, with each one possibly needing to be addressed and controlled in a different way.
What's the difference between home and industrial applications? For the purposes of what is being done, nothing. They are simply seperate instances of a general problem: addressing and controlling a network of IoT devices.
Developing DeviceJS might have been the single biggest part of WigWag, but once done, many things are possible. And WigWag stated plans to make it open source, so developers encountering things the library doesn't support can contribute updates to add them.
The underlying notion - abstracting the underlying IoT devices behind a JS library - strikes me as broadly applicable beyond what WigWag is doing.
Thanks for your response, DMcCunney. Have you heard of Message Queuing Telemetry Transport (MQTT) (see http://mqtt.org/) I heard about it on a press junket a few years ago. Arlen Nipper, the co-founder of MQTT (he's with Eurotech, which is using MQTT in its M2M systems), was talking about Java and how it can produce less buggy products than other frequently used languages. I remembered how Java was a popular topic for embedded systems design about 10 years ago, and then it faded. Eurotech sent me a short primer on MQTT for publication.
Java is one of the languages I thought of as appropriate for this sort of usage. The main reason is the cross-platform nature. Java is "write once, run anywhere". Java compiles to tokenized bytecode, interpreted by the Java Virtual Machine, and the bytecode is the same regardless of the machine you compile it on. JVMs exist for almost everything. (I have one IBM created for PalmOS devices.) You can write Java code and compile it, and run the compiled code on a completely different architecture or OS. I have Eclipose, written in Java, here. The same binaries run on Windows and Linux.
Susan, the issue with MQTT is that it is focusing on the wrong issues : while it _can_ be used between two IP devices, ans looks neat for implementing publish/subscribe mechanisms in lightweight clients, in practice it has no real additional value as compared to HTTP. The reason is that mainly when you have IP, you also need DHCP, DNS, etc. so HTTP additional weigth is a non-issue. OTOH, there are millions of web servers available with published APIs, but very few MQTT public sources of information. And all the presumed specific features of MQTT (QoS, etc.) are pretty useless because there is for example no good coverage of broker discovery or authentication. After some research, I think I understood why some people push it so hard for M2M (closed) systems : it is simpler than the legacy AMQP protocol used before, and also in hands of OASIS. But M2M and IoT are different beasts.
Actually, I don't ;-) Why would IoT differ from telematics ? Quoting that article, "It was typical to see projections of $40B industry in just three years."
If the only difference between IoT and M2M were the use of HTTP, then it would be true. But it isn't.
M2M is far from dead because it is vertically integrated, and limited to valuable niches, with carefully crafted ways to exchange information. Sadly, 90+% of IoT discussions are still about "connecting everything". That makes no sense. My TV is "connected". My game console is connected. Still most of the time I look at broadcast and play games locally. And I guess I'm not the only one.
Another myth in that is "since the Internet of Things allows us to measure everything, it now allows us to manage everything". This assumes someone paid for 50B sensors without any RoI calculation ? If that's a private network, then IoT is simply a slight cost reduction by replacing some legacy network technology by IP? But which, GPRS? it's also IP ! If the target is a truck, today, There Is No Alternative !
So no, M2M is not the father of IoT. Rather a cousin. Sure in the future there will be more Bluetooth than RS485. So what ? You'll have more batteries to replace !
About standards, of course they are needed. But there are too many, and not the right ones. Only the real market can decide which standard is good. Today it's more of a Real vs WMV vs Quicktime situation. Then Flash came and eat them all, only to be eaten by HTML5 (almost Quicktime ;-).
Platforms ? There he's right. Look at Linux/Android, or ARM/cortex.
Patents ? Can be good or evil. I think mostly evil though, even if I wrote some ;-)
As per previous comment... yes, devicejs.org is not glued to WigWag per se. You will be able to take it, run it on other hardware, and build custom systems. WigWag uses it as the basis of their platform - but it is a layer underneath their services.
So this effort rests on top of already well understood and widely deployed components. There are all manner of possibilities beyond WigWag's initial uses.
Coversant, a platform provider is currently engaged with aicas and thier java based Jamacia products. XMPP is now being standardized as the federsation and communications protocol for IoT in the ISO/IEEE/IEC 21451-1-4 WG as well as other data protocol standards groups. Many of the data protocols have java implementations, OPC UA for example, or you can easily place an XMPP client on the device, amount of device memory usually dictates client. There are controller products such as i.LON from Echelon (this is usually used in legacy buildings that have current devices that run BACnet, LonWorks, Modbus, OPC ect) which transforms/translates all the disparate protocols into XML which can then be wrapped in XMPP and sent to the endpoints applications and humans that have interest in the data or state of presence of the device, oBIX is also an alternative to an external applicance. There is much more on the subject of IoT at mholdmann.wordpress.com.
What are the engineering and design challenges in creating successful IoT devices? These devices are usually small, resource-constrained electronics designed to sense, collect, send, and/or interpret data. Some of the devices need to be smart enough to act upon data in real time, 24/7. Are the design challenges the same as with embedded systems, but with a little developer- and IT-skills added in? What do engineers need to know? Rick Merritt talks with two experts about the tools and best options for designing IoT devices in 2016. Specifically the guests will discuss sensors, security, and lessons from IoT deployments.