• Print

Four short links: 9 June 2009

Biological Radio, Laggy Smart Grids, API Moneys, and Pubsub Server

  1. Drawing Inspiration From Nature To Build A Better Radio — based on the design of the cochlear, this MIT-built RF chip is faster than others out there, and consumes 1/100th the power. Biomimicry and UWB radio are on our radar.
  2. Why the Smart Grid Won’t Have the Innovations of the Internet Any Time SoonWhile it’s significant that utilities are starting to build out smart grid infrastructure, utilities are largely opting for networks that provide connections that are far from real time, and this could stifle the desired innovation. [...] smart meter data that is pushed to Google’s PowerMeter energy tool has to make its way back to the utility before it can be sent to Google. That means that even for Google’s energy tool, there can be both a significant delay before information reaches consumers, and significant gaps in energy data details. These delays and gaps can undercut the premise of how smart meter technologies will empower consumers to make decisions about their energy use based on real-time costs. Smart grids (houses and devices able to take use of instantaneous pricing changes) have the potential to help us with our energy obesity problem, but the architecture must be right.
  3. API Value Creation, Not MonetizationOn the side of the unexpected but interesting outcomes, Kevin said they have seen a flurry of internally developed business applications. In the past many valuable, internal-facing projects were turned down because the programs had to meet strict top line to bottom line ratios. With the availability to data and services, many teams within the company now have access to things they didn’t in the past, and project costs have been minimized. Throughout the company, consumers of the API have been able to launch successful projects that have created additional revenue and have reduced the overall development costs for new projects. Some solid numbers and names to help convince businesses to offer APIs, though the battle is still much harder than it should be.
  4. Watercoolr — a pubsub server for your apps. A channel is a list of URLs to be notified whenever a message is posted to that channel. Clever little piece of infrastructure for web apps, embodying the Unix philosophy of small tools that each do one thing very well. (via straup on Delicious)
tags: , , , , , , ,
  • http://basiscraft.com Thomas Lord

    Re watercoolr,

    Please be careful.

    Watercoolr implements an incomplete protocol (e.g., there are no methods for closing channels or canceling descriptions). It implements an unsecured open relay, inviting DOS attacks, spam, and other purposeful and inadvertent meltdowns.

    It implements (silently) lossy, unordered, duplicative multi-casting and thus is unsuitable other than for protocols layered atop it which are insensitive to those properties.

    It is extremely limited regarding payload types.

    Channels, subscriptions, and messages are in no way authenticated with respect to their originators. Anyone can subscribe anyone. Anyone can transmit on any channel for which they have an id.

    Database integrity is not maintained. Although it is improbable, watercoolr is fully capable of silently assigning the same id to more than one channel.

    Messages are not routable.

    The system does not scale well to cases of a large number of messages and servers on a given hub (requiring, as it does, (NSUBSCRIBERS + 1) connection set-up and tear-downs per message.

    In most commonly encountered situations, using watercoolr would not be a wise idea.

    A lot of people seem to claim, without good support in my opinion, that web hooks are the bee knees because they are so “simple”. The problems with webcoolr are a fine example of how they are not simple at all, unless they are completely non-robust, vulnerable to attack, and not scalable. If they have all of those negative properties, they can be simple.

    Paypal did a decent job for one particular application with web hooks. They did it by taking particular pains to secure their protocol – at the cost of complexity of configuration and implementation.

    At first glance, at least, pubsubhubhub appears to partially generalize what Paypal did.

    Really, the future pretty much has to wind up about where Google is pointing with Wave: XMPP for hubs and federation and, sure, perhaps some carefully crafted Paypal-style web hook gateways on the side.

    Meanwhile, watercoolr is not especially safe for most uses as it stands.

    -t

  • Martin Haeberli

    _why_ does “smart meter data that is pushed to Google’s PowerMeter energy tool [have] to make its way back to the utility before it can be sent to Google”? Of course, the qualifier is the catch: “When Google … works with a utility”. Google of course needs to do whatever Google needs to do. But the utilities are not the customer’s friend, nor, frankly, in my view, are they Google’s friend. There are plenty of solutions here or nearly here (See TED 5000 (http://www.theenergydetective.com/ted-5000-overview.html), for example) that could at a minimum be connected to an embedded system with internet access and feed data directly to Google or anyone else.

    My utility (PG&E) doesn’t act like my friend, nor even really like I am the customer. Of course they don’t; there is no one else in my neighborhood, as a practical matter, than I can buy gas or electricity from. I called them and asked them for a smart meter – their response was essentially – “you’ll get one when it’s convenient for _us_, in about 3 years”).

    I’d love to feed my data to Google, but I am in fact having second thoughts because of this “utility focus”. Perhaps one or more of us should build a Google PowerMeter clone that aggregates data from customers who somehow can already gather it.

    Best,

    Martin

  • http://basiscraft.com Thomas Lord

    I find amusing the prevailing assumption here that (a) Google is your friend; (b) that the consumerist fantasies of a few techies ought to dominate social policy in gov and at utility companies.

    New definition for Web 2.0: If it involves mass surveillance and you can do it, then you should. Sums it up nicely, I think.

    -t

    p.s.: PG&E seems pretty friendly to me. They give me easy enough access to my historic data plus some bonus charts and graphs. Their service folks have been helpful, across the board, in my encounters.

  • http://www.juliocapote.com Julio Capote

    @t

    Keep in mind that I never intended watercoolr to become a public api, but more as an internal service running behind a firewall feeding a bunch of disparate rack applications. The website is merely a playground and shouldn’t be used for mission critical stuff. Even still, let me address your criticisms:

    “Watercoolr implements an incomplete protocol (e.g., there are no methods for closing channels or canceling descriptions). It implements an unsecured open relay, inviting DOS attacks, spam, and other purposeful and inadvertent meltdowns.”

    You are limited to one subscriber url per channel, so using it for malicious purposes becomes rather annoying as you’d have to create a channel per attack URL, and at that point you are more likely to bring down watercoolr before anything else.

    “It is extremely limited regarding payload types.”

    I found this one particularly interesting because if you notice, no processing at all is done on the incoming message, letting it be json, xml or whatever format you wish.

    “Messages are not routable.”

    “The system does not scale well to cases of a large number of messages and servers on a given hub (requiring, as it does, (NSUBSCRIBERS + 1) connection set-up and tear-downs per message.”

    Again, this isn’t meant for mission critical stuff (at least not now)

    “In most commonly encountered situations, using watercoolr would not be a wise idea.”

    Perhaps, I just know that it worked great for my particular situation and maybe it will for others as well.

    Anyways, watercoolr is fully open source, and in early stages of development, updates are coming shortly (some which may address some of your concerns here), and we invite everyone’s contribution.

  • http://www.alexandertolley.com Alex Tolley

    tl: “PG&E seems pretty friendly to me. They give me easy enough access to my historic data plus some bonus charts and graphs. Their service folks have been helpful, across the board, in my encounters.”

    As long as you stay in their narrow little rut you are fine. Try to install a solar energy system and sell back the power as mandated by California law and … PG&E is not consumer friendly, but that applies to most businesses. Businesses try to maintain information asymmetry and do not like the customer reversing the information tables on them. Now it is another matter whether energy monitoring appliances will aid the consumer more than PG&E. My guess is that it won’t help much unless the consumer has access to neighborhood data to use as a baseline. For example, what good is it to know that your house requires X amount of gas to heat to temperature Y in winter when what you need to know is how well your house compares to others and if an energy hog, where the losses are coming from and the likely savings by investing in insulation/windows. This can only come from either knowledgeable professionals (there’s that information asymmetry again) or by the collective smarts using the aggregated data.

  • http://basiscraft.com Thomas Lord

    Julio,

    My complaint and criticism isn’t much directed at you or your application of this tool as to how it was presented here on Radar. I’d prefer to not get into inquiring about and critiquing your specific application.

    -t