For five years we drove a Toyota Auris Hybrid. Now we returned it to the dealer, getting at least half of the investment back. Official reason for getting rid of the car is its non-use; in total we just drove 35000 km in these five years. So standing time is much higher than actual driving time. Inofficially I regard the fuel consumption of this type of car still a mess. In average 5.5l E10/100km is far above the promised 3.8l. I don’t know how it is expected to drive this car? Let it roll down from hills and get a lorry to carry it up again? Going just below 80km/h? However, I declare the hybrid experiment an interessting experience, but failed.
What if
Randall Munroe of http://xkcd.com not only draws fabulous cartoons on math, science and all that, but also explains things that seem not too obvious. Using his phrase of “what if” I’d like to raise a question on the actual sustainability of our current renewable energy installations.
So, there are a lot of wind turbines, solar panels, biogas facilities et cetera that feed their generated current into the utility grid. That is fine and provides a not to be underestimated amount of “free energy” (no political discussion, please). All of these grid feeders are synchronized with the grid’s frequency (50 Hz in Europe) to prevent destructive interference. With the actual frequency also these installations are controlled to supply available current respectively stop to do so, when there is an issue. Now assume a blackout: utilities stop to supply power, frequency drops, parts of the grid go off-grid. For security reasons also all renewables are supposed to stop their supply, not least to prevent utility technicians to be fried when trying to work on a powerline.
Hmmm, so in a blackout situation, when power plants have stopped working, there is actually also no supply to happen from renewables. Too bad, as this at least locally could provide a means to overcome a power failure “somehow”.
I assume that a renewable will start its supply on “seeing” a reference voltage and frequency on the line to feed in (at least solar and maybe biogas driven generators, not wind turbines of course, if pushed into a stop mode).
Now, what is the minimal requirement to be fulfilled for renewables to start production again in a blackout situation? Would a 12V-to-230V sine-wave-inverter on a battery pack suffice as such a reference? Note, I am not talking about island installations here that are supposed to provide their power regardless of the grid to be available.
Wouldn’t that be a nice task for a bachelor thesis? Title: The renewables’ role in a national crises – on using renewable energy suppliers in a national blackout scenario to provide at least local grid availability.
(The correct term for such an independent sub-net is “micro grid” and there is a nice definition available at https://building-microgrid.lbl.gov/about-microgrids – yet there is not too much information on how to actually establish one except for installing an own energy storage for some kilo bucks; the utilities will know why)
grid:camp(<<2016.10>>)
Justin Otherguy from http://volkszaehler.org/ took the lead and planned for the second grid:camp after Brussels in April respectively the 10th elektro:camp to happen in October. Scheduled date is Friday and Saturday, 7./8. October 2016. Agenda and details can be found at http://wiki.volkszaehler.org/ec1610-coordination. The event happened in Appenweier, Germany, on location of Leitwerk AG (many thanks to the generous sponsors!) and addressed a lot of topics around energy management, its analysis and derived measures.
Fluksometer: The Next Generation
Hooray, I became an early adopter of the new Fluksometer, called the FLM03E (‘E’ for Experimental?). After installation in parallel to my existing FLM02, I challenge its new functionality compared to the “proven quality”. All my experiences I collect in https://github.com/gebhardm/flm03 – see the diverse markdown and pdf files for more details.
Brussels
grid:camp(<<2016.04>>) is over and we are back from a prolonged weekend in Brussels. Nice city, really nice; yet I am not convinced to become a cyclist there as I underestimated totally the height differences from the European quarter to “down town”. But back to the grid:camp. It was yet another very interesting event, very well organized by Roel; so a big thank you for bringing us all together once again! The agenda was open, but also packed; starting Friday afternoon there were four talks with a lot of discussion on the open grid initiative itself, regression analysis for obtaining energetic signatures of a household, the new fluksometer 3E to be available soon, and some LoRa sensors enabling a wide-range network. The day ended in a nice vegetarian/Indian dinner at 3E’s common room. Saturday started at nine (for some participants after a rather short night) with a talk I gave on opportunities to deal with own data (see at github–>energyhacks–>ElektroCamp) including a demo of my “MQTT-arduino” setup. This was followed by Justin Otherguy’s introduction on how to actually determine the remaining time available to fire a pellet heating with the given pellets (and ordering automatically a refill). Jan then showed his Python library to access a Smappy setup, followed by an introduction to the “nobel grid”, an European initiative to increase the energy efficiency awareness of households. At this time we already approached 17:00 again, so with respect to being rather tired, we chose to skip the rest – here anyway the idea was to get into more interaction with the open:grid users local to the Brussel’s initiative. Sunday then was sightseeing day; well, snow rain made this a freezing attempt, yet we visted the impressive Atomium (I still believe there is a peaceful use of nuclear energy, if we achieve to solve the litter problem – no, not by letting taxpayers pay for dumping castors in salt mines) – all in all a very nice short trip, surely not the last to Belgium.
grid:camp(<<2016.04>>)
In Elton John’s “Rocket Man” there is the key line “I Think Its Gonna Be A Long Long Time” and I didn’t think it would take that long until a further elektro:camp would take place. Two years went along until I received the invitation to the next event to occur. Now it is called grid:camp and will focus not only on tinkering with energy management itself, but also with the data it produces. So, I am curious what will be the outcome of the meeting to happen in April in surely sunny Brussels. Hope to meet you there in person; get involved and refer to www.opengrid.be for more information.
Better understanding consumption behaviour
Long time no update. Busy or nothing new or just lazy? All a bit, honestly. Nevertheless, I always follow the discussions in the FluksoForum and try to help or provide explanations where possible (sometime quite annoyed by certain TL;DR habits).
One interesting discussion came up on how to show and explain consumption behaviour, not only to children. Well, I am used to graphs, but that seems not to be a convenient solution. Thus, there was the request for a very simple graphics. This should directly show what is produced, e.g. by a PV installation, what is consumed by the household, and what is on assuming production still taken from the power grid – focus is on electricity, of course.
The solution evolved into a simple consumption view, that is presented by following visualization which I made deployable directly on my energy meter – it should be not too difficult to adapt this also for other MQTT sources. If you are interested, visit my Github repository.
Where is my data?
The “Internet of Things” (IoT) was and still is hyped. With all the things publishing their data and receiving others’, there is an ongoing discussion on security requirements and corresponding implementation proposals. Who is the owner of all that data? “I am the owner of my data” here is just “untrue” if continuously sent into the net’s space like a postcard (are there still people writing plain postcards?).
As posted beforehand, I use a Fluksometer, a little “community device” that is capable to measure energy, water and gas consumption as well as supply by an own PV installation or power-heat cogeneration. The measurements are by default published to a community website, as the intention of the appliance is to learn together on how energy is exchanged. While this data posting happens within a “closed community” of similarily interested people (with an open subscription ;-)) and posted data was stored in a round-robin database with decreasing level of details accessible, this seemed justifiable from a security perspective. With an upcoming firmware revision now there is the capability to efficiently store data “on the highest level on detail” for actually any time interval (used is a delta storage format, called tmpo, with accessory compression) on the device and on the website (even though only retrievable by ID and security token), published via MQTT. Retrieving this data is currently only possible via a web-API. Hmmm.
The idea of the storage is intriguing, yet the web persistence and its API providing the only possibility to access the data again, I am not fully convinced of. So, I digged a little deeper into the matter and came to a solution, providing an MQTT-based API directly on the device itself, thus web-publication may be revoked. By this I also learned a lot on “interactive” MQTT messaging, thus publishing a request for a data query and subscribing to an asynchronously sent answer. Here my learnings:
- Data querying via MQTT might not be the best of all design decisions, but it works fine; latency is in the range of latency experienced with a “real” database query on a Raspberry Pi; this especially holds true if there is only an MQTT client and no inherent HTTP server available in the device’s “server daemon”.
- Payloads can be exchanged also in compressed form; issue here is to “know” that a payload is compressed, thus must be received and computed in byte mode unless using, for example a 7-bit coded compression format from ancient times; here with Paho payload recognition must happen with mqttMsg.payloadBytes instead of mqttMsg.payloadString, which raises an error on byte-only content. Correspondingly the retrieval of a JSON object is also a bit more tricky: tmpo = JSON.parse(String.fromCharCode.apply(null, gunzip.decompress()));
- Everything by that can be packed into a html application residing on the device itself; all computation happens on the frontend, thus in the browser which is convenient and rather easy to enhance.
My facit: A thing publishing data by itself is not a great issue as long as the “thing’s owner” recognizes what actually happens with the data; there are options, also with existing methods to keep the data under control without losing any convenience. Yet, at the moment this requires to think beforehand and possibly lay hands on the matter oneself.
For my proof-of-concept, please refer to my corresponding github repository ‘flmlocal‘.
Does a hybrid car pay off? – II
In my previous post on experiences with our Toyota Auris Hybrid I sketched an indecisive picture. This picture today changed to a definite “No, a hybrid car does not pay off“. Why? Rust on the disc brakes in the front and and back of our car make required Technical Inspection Agency (TÜV) approval uncertain; heck, after three years! 400 Eur for a replacement after 24.000km plus the cost of inspection… (sorry, if you regard 400 Eur as peanuts – but this is in addition to the overall impression of the car).
On the one hand Toyota tries to educate me as a driver to accelerate slowly, drive anticipatory, and brake less to recuperate my drive battery. On the other hand the same Toyota tells, that “due to less braking there is the consequence of rust on the disc brakes that just can be reduced by harsh braking” – are they kidding me? What kind of design is this that makes brakes a subject to insecurity?
I must admit, we don’t drive too much; but we keep to the guidance and still use 5.4l/100km in average (just once I reached the advertised 3.8l/100km on a longer distance drive).
By that, I declare the hybrid experiment as failed and would argue that for “low to medium utilization” the extra cost and heavier weight of a hybrid car will never ever pay off.
An Internet of Things reference architecture
At the moment it seems “the world” woke up and “requires to put a tooth” into the trendy (is it still?) topic of “Internet of Things” (what would Steve Jobs have done?). All the “architects” (software and hardware) crawl out of their nests and scream “I have it, I have it, I am the one to revolutionize the world”. Mmmph – M2M is older than I can image, there are standards for communication and implementation already available that could help (see my favorite xkcd cartoon on this), there is an understanding of managing the data produced (hey, not only power plants and planes work like that for quite a while now!), and there are plenty of affordable solutions available that make this topic actually “commodity”, thus “boring”; so why the buzz?
To provide an answer for myself, I guess it is because now really everybody may understand it (understand! – yes, I still have high expectations); it is getting out of the niches of experts into the day to day world, into all homes, not only the super-rich ones, onto any computer, smart phone and tablet “all” own anyway, into each (!) appliance purchased “anyway”…
But still there is the “buzz”; I assume, because it still means a lot of money for the “one eyed coaxing the blind”. However…
If you want to try it for yourself and are eager to not spend a fortune on the “best IoT solution” available, think about the following. This is a very basic “reference architecture and implementation” for setting up an “Internet of Things environment” on your own. This you may achieve with not more than spending some money on an Arduino and some time and willingness:
- You are willing to read a little bit and experiment?
- Check, the most foundational, zeroth requirement is met.
- You own a computer, that is a PC, a Mac, a Raspberry Pi or one of the cheap clones from …?
- Check, first requirement met.
- You are able to install an MQTT broker on this computer? Try Mosquitto.
- Check, second requirement met. This will act as the “Internet of Things mediator”; it will receive and transmit messages to and from all the devices and appliances that you want to make talk with each other. Read about MQTT, a simple and convenient protocol for the Internet of Things; note that there are others that would also fit, but don’t care for now.
- Now a little hurdle: You own an Arduino Ethernet or derivate and are a little bit in programming it?
- Check. This will act as a “thing”, the “MQTT publisher”; maybe a little large, but good enough for our experiments. The benefit of the Arduino concept is, that it provides easy access into the vast extent of embedded devices.
- Making an Arduino an MQTT publisher now is a matter of accessing four add-on libraries and some 200 lines of code; see my little temperature and humidity publisher as a sample; the simpler the sensor access, the smaller the code and vice versa, of course.
- Now a second little hurdle: You are a bit in web programming, that is you “know” what a web server is, what javascript is, and how to write a simple HTML-page (see requirement zero!)?
- Check. If you don’t want to access just the raw messages published, then this is the step to compute and visualize messages sent by your “things”.
- Depending on how sophisticated you want the visualization to be, this is a matter of setting up node.js on your computer, installing some modules, like socket.io and mqtt with the node package manager, and providing a neat little HTML page visualizing your received “thing” messages. As a very simple example, see my “minimalistic gauges“.
For all the rest, digging deeper into the matter, feel free to browse my github repositories. Both, the energyhacks section as well as the flmdisplay part, are actually the foundation of the above written. Within a day or a rainy weekend you should be able to experience your first success in the “Internet of Things”, then you might decide for yourself, how much “buzz” there is.
Have fun.
Energyhacks 