Hello,
I have managed to integrate openHAB with Cambridge Audio azure 551.
Below is my UI
You can find all details (including programs) of my project at:
1 Like
Hi Rafal,
This is absolutely brilliant! I have been looking at IP to Serial devices or the Broadlink to control my AV Receiver but this is such an elegant solution.
However, I was wondering if you could give me a little help?
I am able to receive the status of the Azure but my commands are not being actioned. I think the command message I am sending to the mqtt broker is probably not quite right.
Can you please share what message your mqtt broker sees for topic Azure/command and I will adjust my syntax in openHAB to achieve it.
The image below shows what I am getting when I copy directly from your file.
Thanks very much
Hello,
Initially I used Broadlink as well but due to limitations and some behaviour (unexpected device switch on) I have moved to full integration.
Not sure, do you mean azure_mqtt_client file?
In this file formatBeforePublish defines command to be sent to mqtt broker. For instance for mute:
- id: mute_state
channelTypeUID: mqtt:switch
label: Amplifier mute state
description: ""
configuration:
commandTopic: Azure/command
formatBeforePublish: '{ "mute" : "%s" }'
stateTopic: Azure/status
transformationPattern: JSONPATH:$.isMute
Openhab replaces %s with “ON” or “OFF” in this case.
is it what you’re stuck on?
So I am still using openHAB 2.5.12 and so have configured my Azure mqtt client through paperUI which is a little different to you.
The transformationPattern corresponds Incoming Value Transformations on the Azure/status topic and is working fine and I think the formatBeforePublish corresponds to the Outgoing Value Format on the Azure/command topic and this is the bit I am not sure on.
The image below shows this:
However, I can only see the status of the Receiver update when I press buttons on it locally, I cannot get it to action the commands I send from openHAB. So it means the status topic is working but not the command topic so things are partly working which is a good sign.
My first step in debugging was to understand the output of the Azure/command topic, if that is in the wrong format then it could explain why nothing happens as the code you have written for the Wemos doesn’t interpret the message and action the serial command.
When I query the mqtt server I see the Azure/status and Azure/command topics (shown in my first post) and I was wondering if the Azure/command topic message is in the right format. openHAB is posting the message: command = ‘{“mute” : “ON”}’
If this is the expected message then I will need to move my debugging on to the Wemos.
Thanks for your help.
Yes, formatBeforePublish is visible as Outgoing Value Format in UI.
And the screen and description you have posted from version 2.5.12 above is the same as in version 3.1.
Unless you have changed some part of the code for Wemos (apart from obvious like password etc of course) it should work.
You can check as follows:
0. Not sure if you have bought or built your converter. If it was built ensure Tx/Rx are connected in the proper way.
- Do your items have %s as well in their definition?
Switch CA_MuteState "Mute [%s]" <soundvolume_mute>(gAzure) ["Switch","SoundVolume"] {channel="mqtt:topic:cambridge_audio:mute_state"}
- I would check if the syntax ‘{“mute” : “%s”}’ from version 3.1 works in version 2.5.12 as well?
Seems there were some issues, see the the bottom of [SOLVED] Update item state from MQTT string - #14 by Zugarelli
Make sure to restart Openhab or clear cache
Try with different syntax like {“mute” : “%s”} without single quotes
- If it does not work and the openhab setting seems OK you can check if the mqtt message is delivered to Wemos. You will need to debug in Wemos and in order to do it you need to switch to serial monitor or add ESP8266WebServer.h library to present the staus/display of the selected message (ex mute)
PS. I have decided to migrate to version 3.1 and despite number of bindings and DSL rules I have got it was painless:-). In my case the 3.1 running o RPI3 is more stable than 2.5.12 
Thanks for all your help. I have got it working now.
So there were two issues, I have used the same components that you had used and assembled it on a prototype board. It turns out that the Tx connection was intermittent so that was why it wasn’t sending the serial command. There was also an adjustment required as to the syntax as you suggested {“mute” : “%s”} without the single quotes was required. I had actually tried this before contacting you but the dodgy connection was masking the effects of my changes.
I am absolutely delighted that you posted, its quite a specific solution to a specific problem but it works wonders for me.
P.S. I have started an offline build with 3.2 just to test my existing config etc and that everything comes over but not fully committed yet due to having the time really. However it sounds like I should just go for it.