Installing Qbus domotics controller

Hi!

The docker installation is just an alternative to HA add-ons. You choose the installation method that fits you best.

As I understand it, you use HA add-ons, so you don’t need docker.

For this to work, you need the following:

  • MQTT broker (it’s in the default add-on store)
  • MQTT integration: MQTT - Home Assistant
  • QBUSMQTT add-on
  • QBHA add-on

The last two are in my repo on GitHub - thomasddn/home-assistant-addons: Home Assistant add-ons. Both add-ons are required.

Bedankt Thomas!

This worked! I see al my entities under the MQTT device.
I had my Ubie/Qbus integrated into Google Home, now I removed this integration to have them only in HA.

However, I would still like to control my Qbus devices with my voice (using nest mini’s) but this doesn’t work anymore…

I have all of them exposed to Google Assistant in HA but when I open up the Google Home app for example, the curtains show offline so I can’t control them. (see screenshot)

Should I re-add the Ubie integration in Google Home then?

Thank you

Do you actually have a dedicated Ubie box? Apparently you can not use Ubie box in combination with HA, according to Installing Qbus domotics controller - #10 by tmvvk. But you could try to see if it works.

I don’t have Google Home, so I’m a bit in the dark here.

A few questions:

  1. Are the lights in the screenshot Qbus entities?
  2. Are there any Qbus entities from HA that work in Google Home?
  3. Are there any other (non-Qbus) entities from HA that do work in Google Home?

I do have a Ubiebox connected to my network yes. However, I unlinked it from Google Home to make sure I only have the Home Assistant Nabu Casa integration with Google Home.

  1. The lights in the screenshot are a HA Group of 2 light entities
  2. Yes, seems to be only curtains that aren’t displaying well in Google Home
  3. Yes, there is one entity (Renson Ventilation) and an entity from Somfy (sun blinds) in Google Home that work

A few more questions:

  1. Are the curtains visible in HA via QBHA?
  2. If so, I assume created as a cover?
  3. If so, only up, down and stop actions?
  4. Is there a way to remove and re-add the cover entities in your Google Home?

Would you mind sharing your qbusconfig.json file? If you prefer to do this privately, you can upload it to https://www.dropbox.com/request/HUOcZdKk6TE3AOJWwBuz (which is write only, no one besides me can read).

  1. Yes
  2. Correct, all entities have “cover.”
  3. Correct
  4. Scared of doing this tbh. I’ve nearly lost a day yesterday in trying to troubleshoot my Google Home + Assistant devices.

I’m not sure it’s even an issue anymore because I can control the curtains in HA using Google Assistant.
For some reason they just show up as offline in Google Home.

Thank you Thomas

Great news! Qbus now has an official integration which I helped develop! :raised_hands:

Please note that at this time only on/off is supported. HA only wants one platform to be included for new integrations. So in the coming weeks, other outputs will be added.

What does this mean for the add-ons?

  • Qbus MQTT Gateway is still required
  • QBHA is deprecated and no further development will take place

Hi Thomas, can both addons exist together? so we can test the official first before we remove everything…

thanks

Yes, you can run them side by side.

:ok_hand: super! will dive into it now.

Hi
I read already in this post that it is not possible to connect an ubiebox and HA at the same time to the CTD.
I suppose this is still the case?
I have an ubiebox to be able to control my hue lights with the qbus buttons for a couple af years.
Now this month i also installed HA to do some energy monitoring because i get the digital meter next month.
I wanted to use the state of my qbus outputs to make virtual energymeters, but the state isn’t refreshed in HA.

Is this still just not possible with also the ubiebox connected?
The CDT is able to gave the state, because i imported the QBUS already 2 times, and during the import i get all the current states (temperatures, outputs,…) but afterwards it doesnt update.
I am also able to control outputs with HA, but i don’t get feedback afterwards of the change in state.

In the qbus MQTT i also find folowing messages:
W20251027 09:30:22.428720 135 ControllerInfo.cpp:190] Invalid controller found: Id: , Serial: 001209, Ip: 192.168.1.154, Auth: , XportVersion:
W20251027 09:30:22.428761 135 Discovery.cpp:188] Controller contains incomplete data: Id: , Serial: 001209, Ip: 192.168.1.154, Auth: , XportVersion:

Can you try to disconnect the ubiebox, restart HA and then see if it all works in HA?

After disconnecting the ubiebox everything seems to work.
I get feedback from all lights and updates from temperatures.
After reconnecting the ubiebox it immediatly stopped working.
I hoped HA kept working and the ubiebox could only send commands without the feedback, that would be ok for me because i don’t use the cloud connection and ubiebox is only used to be able to control hue lighting with the qbus buttons.

You could remove the ubie and control the hue lighting with HA by using an automation.

Very simple representation of the automation:

trigger: switch x = on
action: hue = on

EDIT: Sorry for the late reply, but I was only notified today by email

Hi Thomas, great !
I was already using the MQTT Gateway and QBHA.
I now disabled QBHA, and everything is still working.
In QBHA it was possible to mention binary-sensors in Qbus to ignore, also a list of climate settings are in there.
I don’t know where to put this information now.
Also, even when QBHA is completely disabled (but not removed from the add-ons) I get this error every time HA or MQTT restarts: “Platform qbus does not generate unique IDs. ID ctd_00xxxx_connected already exists - ignoring binary_sensor.ctd_00xxxx”.

  • Is it safe to remove QBHA
  • Where do I put the binary sensors to ignore
  • Is the “unique”-error gone when I remove QBHA completely
  • Will all the entity-names remain the same?

Thanks

Hi Yves!

  1. Yes, you can safely delete QBHA.
  2. This is not supported in the core integration.
  3. The “unique” error is probably caused by orphaned topics on the MQTT server. There is no migration that removes these, so you’ll need to remove these manually. Delete every Qbus related topic under homeassistant. If you have no other add-ons creating MQTT topics for HA, then you can delete the entire homeassistant topic.
  4. Entity names are not the same. You can run QBHA and the core integration side by side and migrate piece by piece. But then step 3 should be done after the migration.

I finally took the time to complete this.
QBHA was indeed safely deleted.
I indeed found out that binary_sensors now show as a regular switch.
I was using nodered for something completely different, a flow created mqtt-topics incorrectly. It was (for me) very difficult to remove them so I combined this with migrating qbus to the build in version. I did shut down mosquitto broker, deleted the add-on, deleted QBHA, restarted HA, reinstalled mosquitto. The warning remains. THe first time after the initial reboot, the second time after renaming the entity.

`Logger: homeassistant.components.binary_sensor
Bron: helpers/entity_platform.py:843
integratie: Binaire sensor (documentatie, problemen)
Eerst voorgekomen: 03:18:12 (3 gebeurtenissen)
Laatst gelogd: 11:42:30

Platform qbus does not generate unique IDs. ID ctd_002585_connected already exists - ignoring binary_sensor.ctd_002585
Platform qbus does not generate unique IDs. ID ctd_002585_connected already exists - ignoring binary_sensor.qbus_ctd_002585
`

Any idea where I have to look ?

Hi! I’ll investigate the warning.

A small status update: I see this also appearing in my logs, but I can’t seem to actively reproduce this in a dev environment. And looking at the code, it should work properly. (Last famous words…)

I don’t think the issue is preventing the integration of doing something, but I’ll keep trying to pinpoint the exact root cause and provide a fix for it.

I think it has something to do with remnants in the HA database. When the old version was installed in the system and later replaced by the new one, the error occurs. When you configure the built-in version in a clean HA installation, you probably will not see it.

At least, that is my educated guess.