Redis is innovative again

ReJSON: Redis as a JSON Store
We’ve created ReJSON, a Redis module that provides native JSON capabilities. ReJSON should make any Redis user giddy with JSON joy.

I have used Redis for many years – both as a database cache and as a super fast in-memory database. But it has not evolved a lot for  a long time.

But this seems to have changed – RedisLabs (the commercial arm of Redis) has released a number of opensource/commercial modules for Redis.

The first one I have looked at is RedisJSON – as I saw the potential to upload a whole Azure Cosmos database for one of my projects into Redis, while improving speed and drastically lowering costs. (Cosmos is well known for being expensive to run.

So I’m currently writing a POC to test out my theories – onwards and upwards.

Raspberry pi, 1wire protocol and stability

After we installed a new boiler and a 10 port manifold to control our (waterborne) I needed to find out which heating loop from the manifold went where without spending weeks on my knees turning loops on and off manually, and then wandering around barefoot to find out which part of the floor was affected.

So I decided to put temperature sensors on every loop and a few other strategic points in the heating system.

So far I have 16 temperature sensors (DS18B20 sensors) controlled by 2 Raspberry pi Zero’s.


Why 2 Raspberry pi Zeros? – Well I ran into problems when I went above 10 sensors on the first raspberry Pi Zero, and decided to see if I could solve this part of the puzzle – as (for all I knew) there was a software or bandwidth limit stopping me at 10 sensors.

The DS18B20 uses a rather ingenious protocol called 1Wire, which enables a “multi drop” configuration of sensors originating from one set of wires. It can be run with 2 wires (parasitic power) or 3 wires (plus, round and data wires). I went for the last one – as using parasitic power sensed one step too far for me. So I used a breadboard attached to the Raspberry pi to make it easier to experiment.


I have had quite a few problems with this – even though the circuit is simple :


I’m using a bit more of a “star” configuration, as each sensor has approx 1m of cable connected to it.

I had a number of problems where the Raspberry Pi’s stopped working at “random” intervals – and lot of experiments with resistor values, swapping of power supplies and so on did not sort the problem out.

The solution to the problem (for me in this particular case) turned out to be the wireless connection to the LAN, as soon as I put a access point close to the Raspberry Pi;s – all stability issues of this type went away!

(More about the setup later)

Beer brewing the nerdy way

Just started a new brew on Saturday afternoon/evening, at now it’s bubbling away merrily.

I have attached the newest birthday gadget to the brewing bucket – my electronic water-lock PLAATO.


As you can see from the picture it’s powered with a standard USB micro cable, and it’s got WiFi built in to store all the data in the cloud – on the accompanying App it looks like this :


The green line is counting the number of bubbles going through the air-lock.

All very exciting – but there were a few gremlins to fight to get it all working. If you look at the line there were very few bubbles before 17:00. In reality there were lot of bubbles before 17:00, they just did not register properly.

For those of you that are home brewers yourself – you will notice that the temperature is quite low. This is because I have yet to find my heating belt for the fermentor. (-;

How to debug networking intermittent problems

We have a flat with very thick walls – giving us problems with wireless connections. We have a mesh network (TP-Link Deco P7’s) with Powerline backhaul. The theory was that when wireless signals could not go through the walls we would fall back to running the network over the mains cables between mesh access points.

The real challenge comes from the difficulty in finding intermittent problems on the network, and the series lack of any decent admin functions on the P7’s.

The mash network has 6 nodes, where the first one is connected to main router with a Ethernet cable. The rest of the mesh is using Powerline or the wireless network between them dynamically. Unfortunately there is no real way to know how each node is communicating with the other nodes.

I’ve tried most things I could think of and feel we are in a good place with the connectivity at the moment, with the exception of my wife’s studio. And kit in the room occasionally has problems.

In the end I installed one of the oldest and first monitoring systems I ever used – Smokeping. And it’s still one of the few latency and network error measurement and login tools I can find. But it’s a very difficult install under OsX – even though I had done it before. So this time I went modern, and downloaded a pre-made setup in a Docker container – and started configuring the monitoring tools.

It now looks like this


And look at the packet loss line – 10% packet loss on average. And it was even worse for the printer :


Average packet loss of 93% – its a wonder it ever works! But both these devices are connected to the same Access point – the Printer using a Ethernet cable – and the AppleTV using wireless.

So now I have a starting point – the cable between the access point and the printer is now the next thing to be inspected – but that’s for another day.

So SmokePing works very well for this type of investigation.

Btw. Here is the page for all access points :


Ikea Trådfri gateway – the trials and tribulations

I started using Ikea’s Trådfri smart lighting soon after it was launched in the UK, and so far I have motion sensor, lightbulbs, control outlet, a light panel and their LED Drivers.

It all works, sort of. It’s not a bad idea, and when it works it’s ideal for the kind of flat we now have, where the living room has multiple lighting circuits and > 24 light points.

But here comes the challenges – at some stage you want to automate your system with one of the IOT control system from for example Apple – their Home system. So I bought a Trådri gateway, plugged it into the house via Ethernet and configured it.


It all worked well for a period of time, but then it lost contact with Apple Home, and I tried to add it in again. And I tried everything I could find, including resetting both the gateway and Apple home, removing all bulbs and remote controls, resetting all remote controls etc. I even changed the names of all bulbs to something very simple and using just English language – as it was clear it struggled with Scandinavian characters and special characters.

This went on for more than a month, and after having read all Reddits I could and tried all the solutions other users had found I went for the last ditch one – and bought a new gateway.

This worked – and now I have a system working, after manually adding 28 bulbs, 4 remote controls, 2 outlets and 2 motion sensors. And they all had to be added in both Tradfri and in Apple Home, but it works so far.

Ikea – this is not good enough, and this is possibly why new additions to the Trådfri family has been delayed. The idea is good – but the execution is not good enough.

Apple HomePod – a first weekend impression.

Our HomePod arrived in the first batch sent out by Apple – in other words on Saturday February 9th.

I will not bother you with unpacking details – but go straight to the first impressions :

– Siri now works very well, comparable to the Google Home (there is one of those in the house as well)

– The integration with Apple Music works flawlessly (almost)

– The setup procedure is extremely good

– The Homekit integration is not up to scratch.

– Airplay works,

– The sound quality is good for it’s size, but not to audiophile standards.


Siri works a lot better than I’ve ever seen it work on any other device. To be honest I’ve been unimpressed with Siri until I got the HomePod. I’ve quite possibly been spoiled by the Google Home speaker, where voice recognition works extremely well. I have to add that I have a reasonably strong Norwegian accent – enough to make working with various voice recognition systems (except for the Goole home) has been a bit of a hit-and-miss affair on occasions.

But as long as the HomePod is not hidden behind anything it works every time, even at quite a distance (12 foot) and even when playing music. Very impressive, especially seeing some of the artists I ask for songs by have weird and wonderful names.

Sound quality

I used to design and build professional sound studios and speakers for a few years – and have decent speakers at home (QUAD ESL and REL Sub). So iI have a fairly good idea of what makes a audiophile quality speaker.

And the HomePod is not bad, and even fairly good for it’s size. It beats most small speakers, and among these I count the Google Home speaker and the Amazon Alexa speaker. And it’s very dependent on positioning. Putting it in a corner makes it produce surprisingly good bass, but it then struggles with the midrange.

Make no mistake – it’s built for background musing around the home or office where the convenient access to your Apple Music library trumps HiFi listening, and it does this in spades.

It makes me listen to more music than I have for a long time (I’m not allowed my HiFi speakers in our living room (understandably) – but the HomePod can be used – as it looks good, and is smaller than you would guess from the pictures I have seen.

reliably detecting the presence of IOS devices on your network

One of the challenges in having a good home automation system is how to detect the presence of people in the house. I’ve had many tries on doing this, among them:


– Movement sensors.

These work – but for a big house you need a lot of movement sensors if you are going to have good coverage, and they do not work in practice in our house.

– iBeacons

Generally need to track a Bluetooth device, and unless you can get every household member to carry a bluetooth device, this is unworkable. The best idea would be to use a ibeacon running one a mobile phone, but these would include installing software on every household members mobile phone, not workable in practice. The option is to detect each phones bluetooth interface, but this is again not applicable for IOS devices (more about that later) – or without reducing battery life when the phone is outside the range of your house. The range is also very short, and means that you would need (potentially) a lot of receivers.

– Check for the presence of mobile phones.

You can unfortunately not ping IOS devices after that have entered deep sleep, nor use ARP to detect them.


As our household is run on iPhones the last has been a problem – until I found a reference to how to wake up a IOS device from deep sleep by sending packets to port 5353 (mDNS port) to wake it up, and the use ARP to check for the presence on the network.

This is a excellent way of doing detection, as the only downside is that it will lead to more battery usage (as deep sleep reduces the devices power consumption drastically). And of course it was very clear that a way to do this had to exist – otherwise you would not get alerts/messages/emails wen the IOS device was in deep sleep.


How to do this in practice

After installing hping3 (I did this on a Raspberry Pi by using arp-get install hping3) i made a very short shell script


sudo hping3 -2 -c 10 -p 5353 -i u1 $1  2> /dev/null 1>/dev/null

arp -an | egrep -w $1


it works (though not perfectly) as it wakes up the IOS devices, and responds like this when it finds a device



? ( at b4:f0:ab:c5:62:dc [ether] on eth0


and for a device that is asleep 



? ( at <incomplete> on eth0





Our super new electronic train tickets

I have had one of the new electronic train ticket cards for quite a long time at the moment, but I am unimpressed by some of the system.

Every morning for the last 2 weeks this is what the electronic sensor at my trainstation looks like :

IMG 4697

It’s been rebooting for 2 weeks.

On the train the onboard staffs readers seem to be malfunctioning or out of battery more than 50% of the time. Even when they work they take 4 times as long to check as the old fashioned tickets.

Not terribly impressive.

The networked Max! thermostat works

As can be seen from the graph the new thermostat seems to work as it should. And the controlling software (FHEM) now runs off a Raspberry Pi.


The red line is the set point temperature

The violet (?) line is how many percent the radiator actuator is open.

The green line is the room temperature as measured by the thermostat.

Btw. this is from today (Sunday) – and it was down to freezing last night.