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 ;-)

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.

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.

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.

Note that Java and JavaScript are two very different things, whose only similarity is Java in the name, Java was created by Dr, James Gosling at Sun Microsystems. JavaScript was originally written by Brendan Eich for Netscape Navigator 2, and called LiveScript. Calling it JavaScript was a Netscape marketing decision to capitalize on the popularity of the then new Java language, and has caused endless confusion since among folks who conflate them. (These days, Brendan is Mozilla's CTO, and leads their JS development effort.)

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.

Thanks for the pointer. The code isn't up on Github yet (that's promised for November), but they're using Google's V8 JavaScript engine (which is used in Chrome), along with the widely used Node.js library, and a real-time JSON database. JSON is also widely employed, with a simple and easily parsed structure.

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.

V8 is using JiT compilation techniques to compile JavaScript to native machine code before execution, so there shouldn't be an efficiency penalty in using JavaScript for this purpose, either. (The issue faced by both V8 and Mozilla's IonMonkey JS engine is determining when it's faster to just interpret the JavaScript instead of compiling first, and lots of work has been done on that.)

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.