OK Homey, you’re fired

Well..OK, let’s just wait and see if you can evolve to a mature product in the next couple of months… you’re still beta, so who knows what’ll happen in the near future. I’m one of the backers of the Kickstarter Homey project – I already knew about it before it appeared on KS because there already were rumors about Homey on Tweakers before the Homey KS started. In the past I tried several other solutions to get speech going in my Home Automation but never really found a really good and reliable solution; maybe Homey then? So I decided to go for the GEEK Edition: “You will receive Homey, plus two wireless transceivers, enough jumper cables to hook it up and early access to the SDK including sample code for your Arduino projects!

 

Does it blend?

Does it blend? It sure looks cool with its rotating LED

 

ETA was May 2015 but I’m used to that on KS – either the projects don’t deliver at all (Plugaway, Zano) or much too late. And I don’t really mind the ETA actually, as long as the product meets the expectations. Expectations that were brought to life by the “über-cool” video’s provided on KS. But can the end product live up to those expectations? Here’s my verdict at this stage of the product.

The Homey arrived on February 10th. I was too busy with other projects so I couldn’t spend much time on the Homey, but I just couldn’t resist doing the initial setup. So I did and half-way (the 2nd trial to finish the setup) I came to the conclusion that Google Chrome was mandatory to successfully finish the initial setup. Hmm, someone could have told me so. Not much happened since then besides some late-night experiments with different languages, voices and such. Cause my primary objective is not to use Homey as my Home Automation system – I already have one 😉 Homey is too limited as a replacement; I’ve got too much ‘exotic’ hardware, a great rules/scene engine and don’t really want to rewrite my whole system to become a bunch of Homey Apps. I’m satisfied with my system as it is right now. Completely NodeJS based, running hassle-free for more than 2 years now.

All I want is a superb Speech Recognition system that I can embed in my own system. That’s all. Let’s examine some of the results of speech recognition.

After the Homey arrived, the first question I asked myself was: how do I get the speech recognition results from Homey to my HA system? First thing I did was looking for a Homey App that I could use in some way – the HTTP request flow charts App by Erik van Dongen looked interesting so I installed it and made my first flow which used Erik’s App to PUT the recognized text to some server and repeat what was recognized through the Homey speaker:

Homey Flow

A tiny NodeJS app was enough to display what was PUT : the JSON contains what was recognized and [..] contains the actual text spoken)

>node homeyspeech.js
14:26:45 > {"tekst":"radio aan"}
14:26:56 > {"tekst":"radio huis"} [radio uit]
14:27:24 > {"tekst":"tv aan"}
14:28:04 > {"tekst":"wat is het weer"}
14:28:27 > {"tekst":"hallo"}
14:28:51 > {"tekst":"nederland en aan"} [nederland 1]
14:29:03 > {"tekst":"de lampen aan"} [doe de lampen aan]
14:29:15 > {"tekst":"no"}
14:29:28 > {"tekst":"lampen aan"}
14:30:25 > {"tekst":"lampjes uit"}
14:30:41 > {"tekst":"alarmcentrale aan"}
14:30:55 > {"tekst":"alarmcentrale uit"}
14:31:07 > {"tekst":"alarmcentrale bosch"} [alarmcentrale home]
14:31:29 > {"tekst":"waarom luister je niet"}
14:31:45 > {"tekst":"het wordt niks zo"}
14:32:02 > {"tekst":"doe je oortjes is goed om te"} [doe je oortjes eens goed open]
14:41:05 > {"tekst":"hoe gaat het met je"}
<switched Homey language to English>
14:46:49 > {"tekst":"lol"} (my son taking a peek over my shoulder, laughing)
14:48:28 > {"tekst":"whats the time"}
14:49:00 > {"tekst":"whats the weather"}
14:49:32 > {"tekst":"no"}
14:50:11 > {"tekst":"how are you"}

Sorry, this is mostly Dutch (of course), which is still in Beta (as it seems, reading the Athom forum).

Good? Bad? I don’t know yet. Homey seems rather sensitive to background noise, a small pause between “OK” and what you named your Homey (here it’s named Ultron right now) can help a lot, Dutch language seems to be harder than English (what the … ???) and after placing the Homey in the living room, near a TV (with its speakers off, sound is provided by a surround system) the results got worse…

More later…

Adding a Plugwise Smile to the Fibaro HC2

Yep, I’m still alive 😉 The ‘silence’ since April this year was simply because I really needed some sort of ‘sabbatical’ after almost 10 years of spending a great deal of my spare time to Home Automation – and some other (more important) things happened in the past months as well. But last week something happened that brought back the inspiration to write a new post.

I think it must have been about 2 weeks ago when Marco from Mood LedLight contacted me to help him to get some information the Plugwise Smile can provide into his Fibaro HC2. He was probably inspired by my post about getting Smart meter data into a HC2. And Marco is the one that advised me on my Gazebo LED project some years ago and he’s my LED strip supplier. I don’t own a Plugwise Smile but thought I’d give it a try – if it can be done I should be able to do it, right? 😉

Marco sent me some info about the progress he had already made – he used a PHP script to query the Smile and write the result to a file on a Windows 2008 IIS server and read that file from a lua script in a Fibaro virtual device and actually wanted to get rid of the PHP part.

The only part I did was getting the authentication working so that it was possible to get the Smile XML data without the use of the Win2k8 Web server. For the last part, XML parsing in Lua, I didn’t have enough time so I asked Marco to seek for help on that from the real Fibaro Lua script cracks – cause I only know the basics. 3 days later Marco had found the solution; here it is… have fun!

--[[
%% properties
%% globals
--]]
 
-- Virtual device id
vDevId = 102
 
-- url van PI met meterconnectie
PI1 = Net.FHttp("192.168.xx.xx");
PI1:setBasicAuthentication("smile", "fake");
 
-- ophalen JSON info
response, status, errorCode = PI1:GET("/core/modules");
--fibaro:debug(response);
 
-- Meter info ophalen 
--local a = string.match(response, "^.+<vendor_name>(.+)</vendor_name>.+$");
--local b = string.match(response, "^.+<modified_date>(.+)</modified_date>.+$");
--local c = string.match(response, "^.+<created_date>(.+)</created_date>.+$");
--local d = string.match(response, "^.+<vendor_model>(.+)</vendor_model>.+$");
 
-- Uitlezen meters
local e = string.match(response, "unit='W' directionality='consumed'>(.+)</measurement>.+$");
local e1, e2, e3, e4, e5, e6, e7, e8, e9 = string.match(e, "(%x.+)%s(%x.+)%s(%x.+)%s(%x.+)%s(%x.+)%s(%x.+)%s(%x.+)%s(%x.+)%s(%x.+)");
 
-- omzetten naar decimalen
local e1 = string.match(e1, '%d+')
local e2 = string.match(e2, '%d+')
local e3 = string.match(e3, '%d+')
local e4 = string.match(e4, '%d+')
local e5 = string.match(e5, '%d+')
local e6 = string.match(e6, '%d+')
local e7 = string.match(e7, '%d+')
local e8 = string.match(e8, '%d+')
local e9 = string.match(e9, '%d+')
 
-- Totaal tellers (dag+nacht-teruglevering)
local e10 = e8 + e9 - e6
 
-- delen door 1000 voor KwH
local e6 = e6/1000
local e8 = e8/1000
local e9 = e9/1000
local e10 = e10/1000
 
-- afronden op 2 decimalen
local e6 = string.format("%.2f", e6)
local e8 = string.format("%.2f", e8)
local e9 = string.format("%.2f", e9)
local e10 = string.format("%.2f", e10)
 
-- waardes weergeven
--fibaro:debug("vendor name :" .. a);
--fibaro:debug("vendor_model :" .. d);
--fibaro:debug("modified date :" .. b);
--fibaro:debug("created date :" .. c);
fibaro:debug(" Huidig gebruik : " .. e1 .." Watt" );
--fibaro:debug(" waarde 2 : " .. e2 );
--fibaro:debug(" waarde 3 : " .. e3 );
--fibaro:debug(" waarde 4 : " .. e4 );
--fibaro:debug(" Nachtteller totaal : " .. e5 .." KiloWatt uur");
--fibaro:debug(" Dagteller totaal : " .. e6 .." KiloWatt uur");
--fibaro:debug(" Totaal tellers : " .. e7 .." kiloWatt uur");
--fibaro:debug(" waarde 5 : " .. e5 );
fibaro:debug(" Terug Levering totaal : " .. e6 .." KwH");
--fibaro:debug(" waarde 7 : " .. e7 );
fibaro:debug(" Nachtteller totaal : " .. e8 .." KwH" );
fibaro:debug(" Dagteller totaal : " .. e9 .." KwH" );
fibaro:debug(" Totaal tellers : ".. e10 .." KwH" );
 
-- Update virtual device
fibaro:call(vDevId, "setProperty", "ui.lbldagverbruik.value", e9.." KWh");
fibaro:call(vDevId, "setProperty", "ui.lblnachtverbruik.value", e8.." KWh");
fibaro:call(vDevId, "setProperty", "ui.lblactueelverbruik.value", e1.." Watt");
fibaro:call(vDevId, "setProperty", "ui.lbltotaalverbruik.value", e10.." KWh");
 
-- Temp dag start ophalen en aftrekken van totaal om dag totaal te berekenen
local myVar1 = fibaro:getGlobalValue('Watt_today_start');
fibaro:debug ("waarde van de variable dag start is ".. myVar1);
local myVar2 = fibaro:getGlobalValue('Watt_Temp');
fibaro:debug ("waarde van de variable dag totaal is ".. myVar2);
local myVar3 = (myVar2 - myVar1);
local myVar3 = string.format("%.2f", myVar3)
fibaro:debug ("waarde van de variable dag gebruik is ".. myVar3);
fibaro:call(vDevId, "setProperty", "ui.lbltodayverbruik.value", myVar3.." KWh");
 
-- Gisteren
local myVar4 = fibaro:getGlobalValue('Watt_yesterday');
fibaro:call(vDevId, "setProperty", "ui.lblyesterdayverbruik.value", myVar4.." KWh");
fibaro:debug ("waarde van de variable gisteren gebruik is ".. myVar4);
 
-- update global variable
fibaro:setGlobal("Watt_current", e1);
fibaro:setGlobal("Watt_Temp", e10);
fibaro:setGlobal("Watt_today", myVar3);
 
-- ff 20 seconden slapen
fibaro:sleep(20*1000)

 

 

Happy Days

Solar Production 1Who said that starting with solar panels during the winter ain’t fun? Wrong, it’s the best time of the year! 🙂
Soon after our solar panels were installed it became a habit to take a peek each day at what the panels had produced. And not being used to large production numbers, you can’t be anything else than happy with what you see; even if the production is just a few kWh.

But then, somewhere in January, you’ll start to notice that the production gradually becomes higher and higher – wow! The sun still has its bad days of course, but the production on sunny days just keeps on getting higher and higher.

So every day there’s the possibility of a new record in terms of energy production and it’s soo nice to witness that – it’s addictive. Nowadays, when I get up in the morning, I take a look outside to see whether it will be a sunny day or not; while at work I keep an eye on the cloudiness and monitor the solar production to see if another record is in the making. So, if spring itself wouldn’t cheer me up (I hate winters), our solar panels would – so right now, every day is a happy day.

If you’re considering solar panels: start in the 2nd half of winter and watch the energy production increase each week; I’m sure you’ll have the best spring you’ve ever had! 😉

Solar2

ESP8266: Good enough for a battery powered sensor?

ESP8266_power_measurements_ battery_lifeDuring the last 2 weeks I’ve collected a lot of ESP-8266 power usage charts as shown here. Enough to conclude that a ESP8266 can be used to build battery powered sensors (e.g. a temperature sensor) but how happy you’ll be after some time highly depends on the report interval. A report interval of 4 samples per hour will lead to a battery life of roughly 1 year. Increasing the report interval to 60 times an hour (once per minute) will lead to a much shorter battery life: less than 3 weeks.

The biggest problem lies in Wifi. It takes my ESP-12 about 1 … 3,5 seconds to get a Wifi connection after waking up from deep sleep. And this is by far the largest contributor to the total time needed to get a sensor value out the door. I tried several things to see if I could shorten the time needed to get a Wifi connection but had no luck; a dedicated AP for a single ESP-12, moving the AP within 2 m. range of the ESP, changing channels – nothing. Maybe turning off (WPA) security may help, but I don’t consider that as a real option. Maybe a static IP address may help (instead of using DHCP) but that’s not a real option either. Increasing the report interval of the sensor is the only thing I can think of right now to get a good battery life (of 1 year or more).

So that’s it, ESP8266 is a no-go? No way! The ESP8266 can still be very helpful in a lot of ways, I’ve had a lot of fun while exploring the ESP8266 and will definitely use them whenever I need always-on Wifi for so,me future project. And I made a nice ‘poor mans digital scope’ during all the fun as well. But it won’t work well when you want to use a relatively short report interval

Is there an alternative for the ESP8266? Lots of ’em, mine is called Zigbee. I’ve been using Zigbee modules since 2010 or so and built my own Zigbee sensors based on a JeeNode + XBee series 2 modules. For motion, temperature, barometric pressure, light intensity (lux). Batteries last about a year, that’s OK. If I would let a ESP8266 do exactly the same thing (with the same reporting interval, sensor type) as a combination of JeeNode & XBee, the batteries would probably last about 8 weeks. Wooaahhh…

I have some unused 3.3V Arduino Pro Mini’s and some XBee’s and will make some similar power usage charts of those; an XBee is ready to send in 35 milliseconds after power-up, so here the numbers will be quite different …

For those interested I’ve put together a page with some of the ESP power usage charts here, so you can see for yourself.

And now it’s time to move on … cause a new Odroid-C1 arrived on which I’m gonna play with OpenHAB, CometVisu, PencilBlue and some more interesting stuff 🙂

ESP8266 current / power usage charts

After a first test with a 4.7 kΩ resistor it was time to connect the INA219 to the ESP8266 + DS18B20 setup I wrote about some time ago. But first I extended the VB.Net app so that I could do the following with it:

  • Set a trigger value so that the app will start collecting the samples after the measured current rises above that trigger value;
  • Set the INA219 Calibration mode from the app, not hard-coded in the Python script running on the RPi;
  • Tooltips for the data points on the chart;
  • Leave a comment in a textbox and a ‘screenshot’ button to save the whole form as .jpg file;
  • Automatic Y-Axis scaling, automatic re-sampling, automatic screenshots (yeah, I love automation…)

I finished most items last Tuesday so now I’m ready to start charting the ESP8266 power usage 🙂

The setup is the same as in the post I mentioned above and I changed the code so that it would mimic Harald Kleins code as much as possible (DHT22 became DS18B20 and MQTT was added) so that we could compare our measurements: Haralds measurements were done with a digital scope + uCurrent Gold and mine with the INA219 (duh). Here’s my current chart (click the image for a larger version with a bigger chart area)  and Haralds version:

INA219 sample of ESP-8266 + DS18B20

What do we see here? A detailed analysis of what’s going on inside the ESP8266 in terms of current draw. The chart is in fact a detailed ‘power map’ cause by calculating the area (mA * milliseconds) between the blue line and the X-Axis we know the power usage for a single sample. With the sample interval, deep sleep current and the power the battery can deliver it should be possible to make a good estimate of what can be expected in terms of battery life. To be continued…

A simple current sensor visualization app

INA219_RPi_VBNet

So what do you do when you want to buy a uCurrent Gold but it’s not in stock? Search for a (temporary) alternative. So that’s what I did and the screenshot above shows what this alternative produces 🙂

An Adafruit INA219 Breakout Board, a Raspberry Pi, a Python script for doing the i2c to the INA219 and MQTT on the RPi, an MQTT broker and a VB.Net app on my Windows machine to collect the data and visualize it with a Chart control. (BTW, the uCurrent Gold has been ordered just a few hours ago – it’s in stock again!)

Most of the time was lost on trying to get the INA219 to work with a Devantech USB-ISS but I didn’t manage to get it working for some strange reason. I even used a BugLogic to analyze the i2c traffic – all I saw were NAK‘s and the USB-ISS I2C_TEST command always returned 0 too; weird.

After I decided to drop the USB-ISS for this and moved to a Raspberry Pi everything went much better. Enabling i2c on the RPi, Python (pip), installing mosquitto, INA219 Python library and I was almost ready – but still not knowing whether this would actually produce something useful…?

The example Python script only needed to be changed a bit:

#!/usr/bin/python

from Subfact_ina219 import INA219
import time
import mosquitto

print 'Starting ...'

def on_connect(self, rc, res):
  print 'Connected'

#On recipt of a message create a pynotification and show it
def on_message(self, data, msg):
  print("%s, %s" % (msg.topic, msg.payload))

client = mosquitto.Mosquitto("ina219", clean_session=True)
#define the callbacks
client.on_message = on_message
client.on_connect = on_connect

client.connect("192.168.10.179", 1883)

ina = INA219(0x41)
client.subscribe("inacommand", 2)

while True:
  try:
    value = ina.getCurrent_mA()
    client.publish("inadata", "%.5f" % value  , 0)

  except KeyboardInterrupt:
    print ' Exiting...Keyboard interrupt'
    break
    
  except:
    print 'unexpected error'

And I added a function to set the INA219 to max 16V and 400 mA and made that the default.

One item left: a tool to collect and visualize the measurements done by the INA219. Whenever I need a quick & dirty app with a form and some buttons I prefer VB.Net – it’s the easiest & quickest way to do small tasks like this. 130 lines of VB code is all it takes… I can expand this app with a lot of ‘extras’  like triggers, setting the INA219 to one of its 3 calibration modes, whether it should publish shunt-, bus- or current measurements and so on. Communicating with the INA219 connected to the RPi is simple, cause it’s done with MQTT 😉 But for now I think this app will suffice.

2-3 hours later I had the app finished for some first results as can be seen in the screenshot @ the top of this post. Apparently the VB.Net receives almost 2800 samples in a period of 5 seconds; that’s about 560 samples/second. Not bad… the screenshot is taken while the INA219 was measuring the current flowing through a 4.7kΩ resistor @ 5V.

Now it’s time to hook up a ESP8266 to the INA219 and start sampling! Don’t know when that will be though …

 

ESP8266 power analysis

mA_measurements

After a lot of hours I think I’ve finally created a way to see what’s going on in terms of power usage while the ESP-8266 is not in deep sleep. Cause that’s just as important as its deep sleep usage. Triggering data collection, getting the collected data to my PC for further processing and charting is what I’ll start working on tomorrow – what will I see once it’s working, that’s the big question right now 😉

ESP-8266: questions, questions

Things are going well with the ESP8266. After almost 72 hours I think that the conclusion may be that the test setup on the breadboard is working reliable; the ESP-12 has managed to come out of deep sleep and read a DS18B20 1-Wire sensor more than 12000 times without any glitch. That’s OK. I also found a way to interrupt the deep sleep it’s in by grounding RST; as far as I know this is the only way to accomplish this. It’s a somewhat strange interrupt of course, cause the ESP is not doing anything while it’s being interrupted … but hey, as long as it does what I need, I don’t care. Maybe wake-up call better describes what it actually is.

ESP-8266 ESP-12

To proceed further and find out whether the ESP-12 can be battery powered (with a minimal battery lifetime of 1 year) it’s time to do some measurements. The power it consumes seems to be documented, but I want to see it myself. Another interesting thing to know is: how long does it actually take the ESP start, connect to Wifi, initialize the GPIO, read the DS18B20, set up a TCP connection, send some data and go back to sleep. And what can be done to keep this period of high energy level as short as possible (or better: as energy-efficient as possible)? Compile the lua code with node.compile() perhaps? I’ll need a more recent firmware for that. And what’s the time from the wake-up call till the TCP server gets the data, short enough to use the ESP8266 for stuff like motion and such? How do I pull the pin to GND with a high signal from a PIR and how do I prevent re-triggering for some time? Questions …

A nice side project I’ll focus on first and for which I ordered some components today, is trying to get some more insight in the power consumption of the ESP-8266 to see if there’s any optimization possible there, without having to buy an expensive scope…

ESP8266: testing deep sleep & interrupts !?


This weekend I’ve been testing one of my ESP-12 module for more than just a few minutes; more like a few hours. Just to see how ‘robust’ the ESP8266 actually is. The story about ‘zombie mode‘, where the module didn’t restart after the deep sleep period had ended, made me curious whether the ESP8266 was stable enough (to use at all).

So I created these 2 scripts to make it do something useful for a change:

init.lua:

FileToExecute="gettemp.lua"
l = file.list();
for k,v in pairs(l) do
  if k == FileToExecute then
    print("*** You've got 5 sec to stop timer 0 ***")
    tmr.alarm(0, 5000, 0, function()
      print("Executing ".. FileToExecute)
      dofile(FileToExecute)
    end)
  end
end

gettemp.lua:

require('ds18b20')

serv_ip = '192.168.10.168'
serv_port = 8001
gpio4 = 2
interval = 20000000
ds18b20.setup(gpio4)

function getTemp()
  temp = ds18b20.read()
  conn = net.createConnection(net.TCP, 0)
  conn:on("connection", function(socket)
    socket:send(""..node.chipid().." "..tries.." "..temp.."\r")
  end)
  conn:on("sent",function(conn)
    conn:close()
  end)
  conn:on("disconnection", function(conn)
    node.dsleep(interval-tmr.now(), 0)
  end)

  conn:connect(serv_port, serv_ip)

end                   

function connect()
  tries = tries + 1
  wifi_ip = wifi.sta.getip()
  if wifi_ip == nil then
    if tries < 5 then
      tmr.alarm(0, 1000, 0, connect)
    else
      node.dsleep(interval-tmr.now())
    end
  else
    getTemp()
  end
end

tries = 0
connect()

Nothing spectacular – it reads a DS18B20 sensor, sends the temperature and some other data to a NodeJS TCP server, goes to deep sleep and wakes up 20 seconds after the previous wake-up, so that the module does this 180 times per hour. It has been running since Friday night.

ESP8266 measuring DS18B20 and going to deep sleep

But then I found another interesting post about deep sleep and interrupts. And if my interpretation is right, this could be what I’ve been looking for – I just had to try it out:

You can easily esp8266 wake from a deep sleep. Just bring on to the RST short negative pulse. I use it.

 

Well…it works! (on a ESP-12 that is, haven’t tested any other model).

ESP8266 wake-up wire

 

Whenever the black wire at the bottom of picture makes contact with the RST pin and effectively pulling it to GND, the ESP8266 wakes up – this needs further research! 🙂

For now, I resumed the reliability test for another night.