Lock YouTube

Inspired by my own LockU2 utility and Useless Box, I came up with a simple and stupid, yet effective, openHAB rule to prevent my kids from watching YouTube when they are not allowed to do so. So first requirement was ability to turn this lock on or off – just added a new switch item for this, and added it to a sitemap.

The rule makes use of the LGTV binding as well as HarmonyHub binding. Without any of these, I don’t think it would be possible to pull off.

Here goes:

rule "Lock YouTube"
when
    Item LGTV_Application changed to "youtube.leanback.v4" or
    Item LGTV_Application changed to "youtube.leanback.kids.v4"
then
    if (Lock_YouTube.state == ON)
    {
        //HarmonyLGTV_ButtonPress.sendCommand("Exit")
        LGTV_Application.sendCommand("com.webos.app.livetv")
    }
end

rule "Enable Lock YouTube"
when
    Item Lock_YouTube changed to ON
then
    if (HarmonyHub_CurrentActivity.state == "Watch TV" &&
        (LGTV_Application.state == "youtube.leanback.v4" || LGTV_Application.state == "youtube.leanback.kids.v4"))
    {
        //HarmonyLGTV_ButtonPress.sendCommand("Exit")
        LGTV_Application.sendCommand("com.webos.app.livetv")
    }
end

This YouTube blocker won’t actually block the YouTube app on the television, but will instead immediately quit the app once it’s launched. If YouType (or YouTube Kids) is already running when activating the lock, it will also quit the app. Update: Changed to use LGTV binding for quitting YouTube – old method commented out.

I almost couldn’t wait for the premiere which was last Saturday morning. I also have a rule in place for generating notifications when the lock has been triggered. After explicitly instructing my son that YouTube was not allowed that morning, only five minutes later I received the first notification that an attempt was made. After that four more identical notifications. Then a final notification that YouTube Kids had also been attempted. Success.

Playing with openHAB binding for Danfoss Air unit

In summer 2019 we had heat recovery ventilation installed in our house: A Danfoss Air A2 unit with a CCM module connected to our existing Danfoss Link CC Controller. The integration here is pretty useless: The Danfoss Link app can’t do anything other than read outdoor temperature and set vacation mode. Even the Link CC is crippled, compared to the Air Dial – for example it’s not possible to read relative humidity, thus completely impossible to check if the system is running as it should.

A few days after installation I added a WeMo Insight integrated with openHAB, so at least I have logged power consumption data since then. Then in November I finally couldn’t resist installing a network cable to the CCM unit as I saw it having an Ethernet port.

I was able to run the Danfoss HRV PC-Tool and finally read some more data like relative humidity. Naturally, next thing on my mind was reverse engineering of the protocol used. I didn’t have to do much research until I found this openHAB Community thread. Reading through the thread ended with the good news that someone already did all the work and even created an openHAB binding.

Fun

Installing the alpha version of the binding couldn’t be any easier and it worked out of the box without any problems. I linked almost all channels and started seeing and logging useful information like operating mode, fan speeds, boost, humidity, temperatures and remaining filter life.

Next, I could start adding rules to actively monitor how the system was operating. I started getting notifications on my phone when boost was activated to get a feeling about when that usually happens. I could also start making humidity graphs, which got me suspicious about these measurements. Comparing with my Netatmo data from four different indoor stations in the house, the Air unit’s measurements are consistently 5-10 % higher. This of course impacts how the system operates, as humidity is likely the only parameter used for calculating fan speed in “demand” mode.

Energy savings

Next revelation came when I found that some of the channels were writable, like operating mode, manual fan speed and boost. Now this turned into something really useful!

The one thing even the Danfoss Link app can do is set vacation mode when away from the house. This will set the HPV to manual fan speed level 1 which consumes about 9 W. So I figured that this could be automated and also used on weekdays some time after everyone has left the house. I used existing presence logic for that (from Unifi access point), but also decided to add CO2 level as parameter for safety. During the night our phones will also go to sleep at some point, so some additional logic is needed.

Trying to perform humidity/demand calculations like the unit itself does would be cool, but also somewhat more complicated than what I had in mind to begin with. Also, it would require me to integrate some new humidity sensors as I don’t want to rely on Netatmo for this, since data is only refreshed every 10 minutes and also Internet-dependent and Netatmo service-dependent. In other words, untrustworthy. But as safety mechanism for presence-flaws and not needing fast reaction, CO2 measurements could be used.

Nest smoke alarm

I also have a couple of Nest smoke alarms which are integrated in openHAB as I haven’t migrated to Google. So why not use them and trigger boost if smoke is detected?

Rules

So here we go. First, I have a rule that will trigger an Android notification when boost is activated. This includes relative humidity from the Air unit as well as from four different rooms in the house, and includes previous values 20 minutes ago. The rule is too ugly to post, and probably too specific to share anyway, so let’s skip it and go directly to the power-saving rule:

rule "Danfoss control"
when
    Item Anyone_Home changed to ON or
    Item SkynetStationIndoor_Max_CO2 changed or
    Item HomeLeft30MinutesAgo received command OFF
then
    var hasChanged = Anyone_Home.changedSince(now.minusMinutes(29))
    if (Anyone_Home.state == OFF
        && !hasChanged
        &amp;&amp; (SkynetStationIndoor_Max_CO2.state as Number).intValue < 500
        &amp;&amp; DanfossHRV_Main_Mode.state == "DEMAND")
    {
        DanfossHRV_Main_Mode.sendCommand("MANUAL")
        DanfossHRV_Main_ManualFanSpeed.sendCommand(10)
    }
    else if ((Anyone_Home.state == ON || (SkynetStationIndoor_Max_CO2.state as Number).intValue >= 700)
        &amp;&amp; DanfossHRV_Main_Mode.state != "DEMAND")
    {
        DanfossHRV_Main_Mode.sendCommand("DEMAND")
    }
end

SkynetStationIndoor_Max_CO2 is a group with function “MAX” being linked from my four different Netatmo CO2 items. HomeLeft30Minutes ago is a manually created item based on the Expire Binding:

Switch HomeLeft30MinutesAgo { expire="30m,command=OFF" }

Updated from presence.rules:

rule "Anyone home timer start"
when
    Item Anyone_Home changed to OFF
then
    HomeLeft30MinutesAgo.postUpdate(OFF)
    HomeLeft30MinutesAgo.sendCommand(ON)
end

rule "Anyone home timer cancel"
when
    Item Anyone_Home changed to ON
then
    HomeLeft30MinutesAgo.postUpdate(OFF)
end

So this first rule will, in a pretty simple way, just switch to lowest step 30 minutes after everyone left the home and CO2 levels are all below 500. This is a conservative way to take control only when assuming no humidity will be generated. Weakest point is that humidity is not considered at all, so for example when drying clothes indoor, rule might trigger anyway.

Next, the smoke alarm rule (still untested):

rule "Danfoss boost on smoke alarm with oven running"
when
    Item NestProtectFamilyRoom_SmokeAlarmState changed from "OK" or
    Item NestProtectHall_SmokeAlarmState changed from "OK"
then
    if (Oven_Status.state != "Off")
    {
        DanfossHRV_Main_Boost.sendCommand(ON)
    }
end

And last, the filter notification:

rule "Danfoss filter monitoring"
when
    Item DanfossHRV_Service_RemainingFilterLife changed
then
    if (DanfossHRV_Service_RemainingFilterLife.state < 10)
    {
        var body = String::format("Remaining filter life: %d %%", (DanfossHRV_Service_RemainingFilterLife.state as Number).intValue)
        // Use some service to push notification, I use Pushbullet.
    }
end

Of course also added a sitemap section to have some app control, since Danfoss doesn’t provide this (in Danish, but you probably get the idea):

openHAB sitemap

Thanks to pravussum for the binding, which can be found here:

https://github.com/pravussum/openhab2-addons/releases/

Update: Officially integrated into openHAB 2.5.5!

Problem with openHAB UniFi Binding

After upgrading UniFi Controller to version 5.12.35 last week, the openHAB binding started having problems with the Online channel. Going from OFF to ON is still detected correctly, but not the other way around. I’m still not sure if this is a problem in the binding, the controller or in my configuration. Only thing I know for sure is that after upgrading the controller image in Docker and the access point firmware at the same time, binding stopped detected our phones disconnecting from the access point.

openHAB is version 2.5.1. I have asked in the openHAB forums, but is still waiting for feedback.

In the meantime I’ve created a work-around using rules. Problem is that once client goes offline, it seems to be excluded from the list fetched by the binding, and channel stops receiving updates. For LastSeen it makes sense, but Online should be updated to OFF, when client is no longer listed. So I used LastSeen to mimic this desired logic in my rule:

var Timer timerUniFiJacob = null

rule "UniFi work-around Jacob"
when
    Item UniFi_OnePlus5_LastSeen changed
then
    if (Jacob_Home.state == OFF)
    {
        Jacob_Home.sendCommand(ON)
    }

    if (timerUniFiJacob === null)
    {
        timerUniFiJacob = createTimer(now.plusSeconds(180), [ |
            Jacob_Home.sendCommand(OFF)
        ])
    }
    else
    {
        timerUniFiJacob.reschedule(now.plusSeconds(180))
    }
end

This rule simply restarts a 3 minute timer on each LastSeen update. When client goes offline, these updates will stop and after three minutes, item Jacob_Home will be set to OFF.

Luxaflex PowerView roller blinds

In 2018 my girlfriend and I decided to invest in new roller blinds for our living room. We needed to cover six windows right next to each other. Luxaflex offered some appealing designs like Duette and Twist. At the time PowerView motorization wasn’t available for Duette, so we settled with Twist. That sums up the introduction and cosmetic part of this review, so let’s move on to the technical part as this is a technical blog. 🙂

Electrical installation

First challenge was the electrical installation, since the blinds are powered by 18 V DC. Had it been 230 V AC (like Somfy), I could have powered them from a nearby ceiling mount, but this requirement had to be planned carefully. I didn’t want to settle with batteries, as I would have to recharge six blinds something like three times per year. I’m pretty sure this would annoy me more than I would appreciate the motorization. Only option for me was to bore holes in the ceiling and supply power from here.

But that triggered next challenge: Where to place the power supplies? It would have to be somewhere reachable and somewhere near 230 V. As preparation I created a new power socket at the attic. However, ultimately I decided to pull 15 meter 2.5 mm² cable over the ceiling to each pair of motors (so motors to the right, left, right, left, right and left) with individual conductors for each motor. All cables end where I have my electrical installation in another part of the house. Official requirement per motor is 1 A/18 V. This is really to be on the safe side and I decided to go a bit lower than that, so settled with a single Mean Well DR-100-15 for supplying all motors instead of two (after performing some tests and measuring the load) – that’s ~5.4 A.

Installation looks like this:

Luxaflex Twist blinds electrical installation. The lose ends are the antennas.

This year we extended our house, and I of course made sure that we would have 2.5 mm² cables with three conductors inside the wall – for each window. This way I’m in full control, and in the future I will be able to easily replace by 230 V motors if needed. The power supply was upgraded to a Mean Well HDR-150-15 which is now supplying all blinds, including three new roller blinds in the extended part of the house (~8 A in total):

Luxaflex blinds electrical installation.

Quick summary: 18 V is troublesome – separate cables needed from all locations to a power supply. 230 V would have been the better choice for easy installation and less cables.

DC connectors

Now next problem. Standard DC 5.5 x 2.1 mm connectors are used. But the motor doesn’t have an internal connector. Instead it has a small piece of cable (~30 cm) with a male connector on it. So keep that in mind, because that connector needs to be hidden somewhere, and it may have to be able to go through bored holes in the ceiling etc. instead of just the cable itself (which would require a smaller hole).

I had to buy as bunch of these female panel mount connectors to be able to fit them and the male connector inside the housing for built-in mounting in the wall:

RF quality

Since PowerView is wireless, we need to look into the RF implementation/performance. The implementation is proprietary, so no integration possible through ZigBee or Z-Wave. Only Hunter Douglas remotes and Hub can be used. The Pebble remote I bought with the six original blinds performs quite poorly. It litterally needs line-of-sight in order to get transmissions through. If I’m behind a corner in the living room (same room) and want to operate all six blinds at the same time, one or two of the last ones won’t get the signal. So performance is similar to IR.

Luckily the Hunter Douglas Hub (Gen 2) has better range. I initially placed it in my server room, not far from the living room, but still two rooms away. Often one random blind would not receive the command, so I had to move the Hub closer. I first moved it into the same room very close to the blinds. That improved the setup significantly, so most times all blinds would react as they should. However, I was told by support that there’s no feedback from the motors, they just receive 3-5 RF impulses and that’s it. So on rare occations, I can still experience one of the blinds not being in the correct position. This year I moved the Hub on the other side of a wall, and range is still acceptable, but not completely reliable. That’s not quite good enough in my opinion for a product in this price range.

Worst part is that communication is one-way. Not only does it hurt reliability, but also synchronization. If the Pebble remotes are used to operate the blinds directly, the Hub will not be informed, and as a result the state is out of sync. This makes it impossible to create home automation rules based on blind state, or at least it will not work in conjunction with the Pebble remotes.

Hardware summary

A small recap before we move on to the fun part – the software:

  • Voltage: 18 V DC – annoying, but not a showstopper for me.
  • DC connectors not integrated – annoying, but I was able to hide them with some effort.
  • RF proprietary protocol – bad.
  • RF range/reliability – bad, and no work-arounds for this.

Software support

Now the fun part and the reason why I went for Hunter Douglas PowerView back in 2018: I knew that it was supported by Logitech Harmony and also by openHAB. Hunter Douglas also made a nice app to configure and control the blinds through the Hub on local network.

App

The app works pretty decent. It’s not without issues, but overall it does its job. Initially it is used to configure the Hub, i.e. add the blinds, so they can be controlled. It can also be used to create automations like “open blinds 10 minutes before sunset on weekdays”. For most common scenarios, where conditions are not needed, this is sufficient. Automations live on the Hub, so there are no external dependencies. However, if you want blinds to open at sunset or 6:30, whichever comes last, you will have to use home automation like openHAB or interface directly with the API yourself.

openHAB

The openHAB binding works like a charm. It let’s you control/monitor each blind as well as trigger scenes. That’s really everything you need. Configuration is easy with discovery and easy adding of blinds as things.

Logitech Harmony

This integration worked out of the box. The Hunter Douglas Hub was simply added in the Harmony app and after that it was easy to add scenes to hardware buttons on my Harmony Elite remote control as well as include a scene in my Movie activity. This means that all blinds will close when starting the movie activity, and two buttons on the remote are dedicated to trigger open/close scenes.

Scenes can be configured to include any blinds in any individual positions. The downside of using scenes is that the motors are operating at slow speed when triggered from a scene (as opposed to direct commands). This is probably implemented this way because the motors are noisy, so when using automation, it wouldn’t be very discrete. However, I would have preferred this to be configurable, and also that the motors were less noisy.

Conclusion

Overall I’m pretty happy with my setup and I have come to enjoy the automation part more and more, especially as we now have nine motorized blinds in the house. Automations based on sunrise/sunset offsets are really nice and convenient. Most of the time we don’t manually control the blinds anymore, as the automation already did what was needed when it was needed.

RF (lack of) reliability is probably the worst part (apart from the installation) since there is no way to fix it. I wonder how it compares to Somfy.

Innr Smart Plug vs. Philips Hue Smart Plug

Quick review/comparison of Innr Smart Plug and the new Philips Hue Smart Plug. First impression:

Side-by-side physical comparison

Innr’s plug is considerably smaller, and the Hue plug actually feels clumpsy next to it:

It’s bigger in all dimensions.

Now, let’s compare functionality. Both plugs have a two-color LED showing whether it’s on or off, and both also have a physical button to turn it on or off. Both plugs are easy to integrate with a Philips Hue bridge and offers the same functionality. The Philips Hue plug also supports Bluetooth.

IKEA Trådfri

Let’s quickly throw in an IKEA Trådfri wireless control outlet before we compare power consumption. I collegue of mine brought one:

IKEA Trådfri

It’s even bigger than the Hue version, and also without any physical button. However, at only half the price of the Hue/Innr plugs, it’s definitely worth considering where size and the physical button doesn’t matter.

Power consumption

  • Philips Hue: 0.1 W when off, 0.8 W when on. (0,003/0,019 kWh in 24 hours)
  • Innr: 0.3 W when off, 0.7 W when on. (0,010/0,017 kWh in 24 hours)
  • IKEA: 0.1 W when off, 0.8 W when on. (0,002/0,019 kWh in 24 hours)

The winner is… Innr Smart Plug when physical size matters. Hue uses 0.1 W more than Innr when on, but 0.2 W less when off, so if turned off most of the time, it might be a better choice. The Hue plug also has Bluetooth, so it can be used without a ZigBee bridge.

In Denmark prices are exactly the same.

LG OLED TV and USB drives

I recently purchased a new LG OLED65C8 TV and with it a SanDisk Extreme Pro USB 3.1 SSD drive with a write-speed up to 380 MB/s, after reading these recommendations. I wanted to use this for recordings and time shift (Live Playback). Unfortunately it doesn’t work with time shift – only recording. I sent a request to customer service about this, and conclusion is:

  • LG recommends HDD’s instead of flash drives. Old-fashioned big noisy hard drives which are hard to fit on the back of the TV.
  • LG cannot recommend any devices – no compatibility lists exists. So customers will just have to buy one device at a time until finding one that works. That’s a very costly solution in my opinion.

Now I’m just waiting for burn-in to complete my LG customer experience…

Update: I got a second response from customer service, and unfortunately – as I suspected:

  • Live Playback only works with magnetic disks, not any kind of flash device.
  • This will not be solved/changed with a firmware upgrade.

Modifying Miele@home prepared refrigerator

I bought a new refrigerator, model K 34673 iD, which I wanted to add to my Miele@home system. It was marked as “Prepared” for Miele@home, which I assumed meant that it was simply a matter of adding an XKS module to it. I already bought an XKS 3000 Z (ZigBee) module two years ago at the same time as I placed an order for the previous model, K 34473 iD. That order was unfortunately cancelled, so I ended up with the XKS 3000 Z module and a retrofit kit, XKV 3000 KF.

The new model was prepared for the XKS 3130 W (Wi-Fi) module, but as this is an upgrade that should be backwards compatible, I had hope that XKS 3000 Z would also be forwards compatible. Back to that later. Both modules look exactly like this:

XKS module

The first problem was that I could not find anywhere to connect the XKS 3000 Z module on the back of the refrigerator as documented. I eventually gave up and desperately created a support ticket at Miele Denmark. A technical employee called me back pretty quickly and instructed me how to perform the operation. This is where the retrofit came into the picture. I was told that I needed a special cable, and that he would send it to me. This is the cable I already got:

Product name: XKV 3000 KF
Materialnummer: 9788210
EAN: 4002515415245

And this it the cable that was sent to me:

Materialnummer: 11034080
EAN: 4002516106159

The cables look pretty identical, but I’m not sure they are. It could actually be the case that some models would need one cable type and others would need the other. Otherwise I don’t see why they would change the product number etc., but of course, you never know.

The modification I had to do involved dismounting the display panel on the front of the refrigerator. A screwdriver was needed to remove the covers on each side of the panel, but this I had to do anyway, since I need to change the door hinging. After reading the manual a few times, I succeeded with this without leaving any visible scratches from the front. Next, the display had to be removed. This can be done without any tools, but it requires a lot of force. The cables are long enough so it can be safely pulled out. It was hard to do, especially at the sides, but it worked out:

Front panel dismounted

Next challenge was to connect the cable and get it to work. This is actually very easy, but a simple mistake delayed my project with more than a week, cost me € 80 and a lot of frustrations. Again I was saved by the same Miele employee that called me the week before.The mistake was this:

Main electronics
Wrong slot

The connector fits perfectly into this socket. But this is the wrong place, and it took me a week to figure that out. In the meantime I was struggling with error “FF” – the refrigerator will not function when a module is connected to this socket. The display will just blink and switch between displaying “FF” and “–“. In the meantime I ordered the XKS 3130 W module, because it could be compatibility issues with the old XKS 3000 Z module, and also this old module wasn’t supported.

The module should not be connected to the main electronics, but instead on the side of the display panel:

Correct slot

After correcting this mistake, everything started to work. I tried the XKS 3000 Z module first, and it worked:

Miele@home configured

Note: It might take up to a minute before the Miele@home logo displays. To perform the configuration click the menu button (second rightmost), then click up or down until the symbol is blinking. Now click OK, and “0” is displayed. Click Up so that it changes to “1” and click OK again. Now add the device on the XGW 3000 Z gateway.

Next I tried the XKS 3130 W module for comparison. The configuration is different. In this case you just have to use the Miele@mobile app to add the module to the Wi-Fi network. This worked out pretty easily.

I haven’t been able to spot any differences in terms of functionality between the two modules, so I have decided to mount the refrigerator with the ZigBee module instead of the Wi-Fi one. Since I own the XGW 3000 Z gateway, this way I will not create a dependency to my router/Wi-Fi network, and the ZigBee module will perhaps even help creating a better ZigBee mesh network together with my other ZigBee Miele@home devices. Functionality of both modules – from app and Homebus protocol:

  • Reading of current temperature.
  • Reading of target temperature.
  • Reading of state “door open”.
  • Starting and stopping super cooling.
  • Starting refrigerator when off (only through Homebus, Miele’s app doesn’t support this).

That’s it. You do this kind of project because you can, and for no other reason. I’m not letting people get to me by asking why. It’s simply because I can, and because it’s fun. 🙂 Time for wrapping up, having the new cable nicely put into place:

Top cover unmounted

And put top cover back on again:

Top cover mounted

The new appliance as seen in the Miele@mobile app:

Power consumption

As bonus info, I made some power measurements before integrating the refrigerator. Here are the numbers:

  • Idle without any module installed: 1.0 W
  • Idle with XKS 3000 Z installed: 1.5 W
  • Idle with XKS 3130 W installed: 1.9 W

Twin refrigerator

Fun fact: Miele K 34673 iD seems to be a rebranded version of Liebherr IKBP 2360-20. It would be interesting to try to integrate a Liebherr refrigerator into a Miele@home system. The model number and serial number is identified though, so it might not be possible. Price difference: >300 EUR.

Things to do with your network-connected Denon/Marantz receiver

This post will focus on the things you can do with your network-connected Denon/Marantz receiver. I bought my Denon AVR-3808 in 2007, so it’s actually my very first IoT device. Unfortunately my receiver doesn’t support the newer HTTP/XML-based protocol or streaming services, but the old telnet-based AVR protocol still gives a lot of opportunities.

So without further ado, a walk-through of options I know of…

App control
Denon doesn’t support the AVR protocol in their app, so third party apps are the only options for me. If you have a newer receiver you won’t have that problem. I’ve been using AVR-Remote for Denon/Marantz for years. It’s a bit old, but still works.

Control with Yatse
Another use within Android is volume control and more within Yatse. Yatse is a full-featured Kodi remote control app and much more. If you have a Kodi media center and an Android device, you should definately give Yatse a chance. And if you use Yatse and own a Denon/Marantz receiver, you should try the Denon/Marantz plugin. Please note that this is a shameless recommendation, since I’m the developer of this plugin.

Control with Tasker
Into automation and using Tasker? Yet another use within Android. Use Denon/Marantz plugin to automate interaction with your receiver. Yes, this is the same plugin as mentioned in previous chapter. Example usages:

  • Mute receiver when phone rings.
  • Use as clockradio: Turn on receiver on radio at 6:00 in the morning.
  • Turn off the receiver when leaving home.
  • Well, whatever you can think of.

openHAB
Staying with automation, integrate your receiver into your home automation when using openHAB. I’m not using this binding myself, since it constantly occupies the only connection available for the AVR, so it would block all other usages. If you have a newer receiver, you won’t have that problem. Instead, I can integrate through the Logitech Harmony binding.

Linux shell script
I wrote this small script years ago and scheduled it to to be run by cron daemon on my server at midnight. Purpose was to save energy in case I’d forgotten to turn off my receiver. It demonstrates how to send a simple command from a shell script, but other than that it’s obsoleted today by openHAB rules or similar.

#!/bin/bash
# Written by Jacob Laursen , 2009-2011.
#
# This script turns off a Denon receiver if none of the listed
# hosts to be checked are up and running.
#
# Options:
# --force : Skip host checking, just turn it off.

HOST_CHECK=`echo {"ps3","smarttv"}`
HOST_DENON="denon"

standby ()
{
        {
                sleep 2
                echo -n -e "PWSTANDBY\r"
                sleep 2
        } | telnet >/dev/null 2>&1 $HOST_DENON
}

if [ "$1" == "--force" ]; then
        standby
        if [ $? == 0 ]; then
                echo "Power turned off"
        else
                echo "Already turned off"
        fi
        exit
fi

host_up=0

for host in ${HOST_CHECK}
do
        ping >/dev/null -c 1 $host

        if [ $? == 0 ]; then
                host_up=1
                break
        fi
done

if [ $host_up == 0 ]; then
        standby
fi

Logitech Media Server/Squeezebox plugin
For controlling volume from my Squeezebox Receiver I’m using DenonSerial v0.1.42 extension by Peter Watkins. I’m not sure where to find it today, as it’s quite old – but still working nicely. An alternative might be DenonAvpControl, but I haven’t tried that.

The purpose of this extension is to set fixed volume to 100% on the Squeezebox Receiver and instead control volume on the Denon receiver. Using this extension should work no matter how you control your Squeezebox Receiver. However, the app (or whatever) must support sending volume commands even for players with fixed volume configured. The Android app Squeeze Ctrl supports this. The ancient, but still excellent, Squeeze Commander does not.

Miele XGW3000 firmware 2.3.4

New firmware, this time noticed a bit late, since XGW3000_version.txt is still showing 2.3.0. I guess I should switch to http://GATEWAY/Rest/Update/ and check “AvailableVersion”, or once again reverse engineer how the gateway checks the version. Anyway, here goes…

Release 2.3.4 – 12.09.2018

  • Improved Miele@mobile behavior in conjunction with ZigBee appliances
  • Stability improvements and bugfixing

Good news is the this fixes the Miele@mobile app so it doesn’t crash anymore on startup. I guess this reveals that they changed the API between the app and the gateway in app version 2.9.4 and didn’t provide backwards compatibility for the existing gateway API. So the app was constantly crashing until the gateway firmware received an update. Not elegant.

First observation: It seems like phases for my oven (H 5581 BP) isn’t supported anymore. Running self-clean/pyrolysis:

Homebus

<information>
<key name="Appliance Type" value="Oven"/>
<key name="State" value="Running" type="state" raw="5"/>
<key name="Remaining Time" value="1:21" type="duration" raw="81"/>
</information>

Rest

{"SignalFailure":false,
"TargetTemperature":[0,0],
"Temperature":[0,0],
"SignalInfo":false,
"ProgramID":2348810240,
"InternalState":0,
"RemainingTime":[1,24],
"RemoteEnable":[0,0,0],
"Status":5,
"ProgramPhase":3072,
"ProgramType":1,
"ExtendedState":"000C100500110000000100000000110400000000000000000018010000000000000000000242000000000000400000000000000000000000000000",
"ElapsedTime":[0,42],
"SignalDoor":false,
"Light":0,
"ProcessAction":0,
"StartTime":[0,0]}

These are my notes for ProgramPhase 3072 and pyrolysis:

			case 3072:
				// Purpose unknown, seems to be set when the oven is just turned on.
				// Catch it here to avoid excessive logging.
				return setPhase(PHASE_UNKNOWN);
[...]
			case 3076:
				return setPhase(PHASE_PYROLYSIS);

Also, temperature is now reported as 0°C. Removing functionality for my oven is just sad, since it’s the appliance with least functionality already (for example, ProgramID’s are not supported). Here’s how it looks in Miele’s own app now:

Miele@mobile screenshot

Update/precision: This bug was probably caused by the fact that I upgraded the firmware on the gateway while the oven program was running. Since the phase didn’t change after the gateway rebooted, the gateway probably had some uninitialized values. I guess it should be possible to query the devices after a boot to get updated values, but I don’t know which limitations may exist. So the bug is there, but it’s rare.

Miele XGW 3000 gateway firmware 2.3.1

New firmware the other day. First it was 2.3.0, then quickly after 2.3.1:

Release 2.3.0 – 01.08.2018

  • Improved device sign on
  • Stability improvements and bugfixing

I wonder what’s in 2.3.1, but probably something was broken in 2.3.0, then quickly fixed.

No changes observed so far. Known bugs persist, new ones not discovered yet. That’s not entirely true. I still don’t know if Miele fixed the random change of name of some appliances. In my case it’s always the dishwasher (my only Wi-Fi device), and I have seen it change to “Oven” or “Washing machine”, i.e. names of my other appliances. Update: This bug is still present.

The app

The Miele@mobile app for Android also received an update a few days later (Wednesday, August 8th): version 2.9.4. This app has generally been of great quality, but this time it’s completely broken:

  • Always crashes on first startup. Never happened before.
  • Notifications doesn’t work anymore.
  • The appliance list sorting algorithm is changed from logical to random, e.g. turned off appliances at the top while other appliances are running.
  • Wrong reporting of power consumption. Reports 1.0 kWh when it should be 0.1 kWh (washing machine).
  • Oven program is reported as “APP_MISSING_LOCALIZATIONKEY_-1946157056 (H 5581 BP, XKM 3000 Z). The JSON value for ProgramID is weird (e.g. “2348810240”), don’t know if this bug is in the ZigBee module, the oven or the gateway. However, the app didn’t show this before.
  • When trying to edit product name to default: Object reference not set to an instance of an object.

It seems someone was back from vacation and decided it was time to push out a new release because of the new Miele logo. But forgot that it was still untested. Please fix. Rescue: Version 2.6.0