Emulated HUE Busch Jaeger free@home not working anymore

I use the Emulated HUE integration to map devices in the Busch Jaeger free@home home control system. That has always worked very well in the past. Now all of a sudden it doesn’t work anymore. It started with the operation of the HUE devices in the free@home. I could turn the devices on but couldn’t turn them off. There was also no feedback whether the device was switched on or off. Then I deactivated and deleted the HUE devices and the HUE emulation from HA in the free@home home control. Unfortunately, the house control no longer finds the HUE emulation from HA. This should actually work automatically. If the home control finds a HUE, it reports for installation. Of course, I’ve already restarted HA and home automation. Unfortunately without success.
Home Assistant runs on an rpi3 and is connected to the free@home home automation system in the same network via a LAN switch.

Here the versions:
Home Assistant 2022.7.5
Supervisor 2022.07.0
Operating System 8.2
Frontend 20220707.1 - latest
Busch Jaeger free@home V2.6.4

In the configuration.yaml I use the following syntax:

emulated_hue:
host_ip: 192.xxx.xxx.x
listen_port: 8300
expose_by_default: false
entities:
switch.alarmcontrol_homeswitch:
name: “Alarmanlage scharf”
hidden: false
light.led_markise_shelly:
name: “LED Markise Shelly”
hidden: false

I’ve also tried a different listen_port 80 - without success.
Does anyone have any other ideas for getting the emulated HUE in the Busch Jaeger free@home home control to work again?

I now had the opportunity to test it with version 2022.7.7 and OS 8.4. Unfortunately without success. But it is interesting that I can pair the Emulated HUE and also see the associated entities. Unfortunately, these cannot be switched. Neither from HA nor from the Smart Home device in which the Emulated HUE was paired. That actually means that the connection is established and that there is basically communication. But why can’t a switching action be executed?

I am also having trouble getting emulated_hue to work. Nothing shows up in http://192.168.0.xxx/api/v2/lights xml file except brackets {}. The http://192.168.0.xxx/description.xml contains a full description:

<root xmlns="urn:schemas-upnp-org:device-1-0">
<link type="text/css" rel="stylesheet" id="dark-mode-custom-link"/>
<link type="text/css" rel="stylesheet" id="dark-mode-general-link"/>
<style lang="en" type="text/css" id="dark-mode-custom-style"/>
<style lang="en" type="text/css" id="dark-mode-native-style"/>
<style lang="en" type="text/css" id="dark-mode-native-sheet"/>
<specVersion>
<major>1</major>
<minor>0</minor>
</specVersion>
<URLBase>http://192.168.0.xxx:80/</URLBase>
<device>
<deviceType>urn:schemas-upnp-org:device:Basic:1</deviceType>
<friendlyName>Home Assistant Bridge (192.168.0.xxx)</friendlyName>
<manufacturer>Royal Philips Electronics</manufacturer>
<manufacturerURL>http://www.philips.com</manufacturerURL>
<modelDescription>Philips hue Personal Wireless Lighting</modelDescription>
<modelName>Philips hue bridge 2015</modelName>
<modelNumber>BSB002</modelNumber>
<modelURL>http://www.meethue.com</modelURL>
<serialNumber>001788FFFE23BFC2</serialNumber>
<UDN>uuid:2f402f80-da50-11e1-9b23-001788255acc</UDN>
</device>
</root>

It appears emulated_hue is actually running given the description.xml contents. I’m also running 2022.07.7 on Raspi but there does not seem to be any new/updated emulated_hue instructions documentation lately. I have a number of lights that work under 107.4 but I can’t get them working under 2022.07.7. Very frustrating.

@bart56 have you had any success integrating Emulated HUE in the meantime? Where do you want to integrate Emulated HUE, also in Busch Jaeger f@h?

Sorry - I should have come back here to say It started working. I had to define the lights in configuration.yaml not just list them under emulated_hue. I didn’t realize that I had forgotten to define them like my previous 107.x system.
All is working it seems except one light I have running on tasmota. It works on my 107.x system, but not here. Still trying to figure that out.
Thanks for asking!

Unfortunately, I still haven’t managed to integrate the Emulated HUE Bridge on the Busch Jäger free@home system. In the meantime, the HomeAssistant Core version is 2022.10.3 Emulated HUE still only works on the smart home control center from Busch Jäger up to HomeAssistant version 2022.6.7 From then on it no longer works.

Pairing is possible and the devices and lamps are also visible in the smart home center. But they don’t respond. It looks like the communication / acknowledgment is not complete.

If, for example, I switch on a HUE lamp in the Smart Home control center, then it is also briefly signaled to me there: the lamp goes on and immediately goes off again. In HomeAssistant, the associated HUE lamp is switched on and stays on. If I then switch off the HUE lamp in HA, it is only switched off in HA.

It looks as if the communication only works in the direction of the Smart Home center according to HA. Nothing works the other way round from HA towards BJ Smart Home Center. Unless the pairing worked.

Obviously the problem is in HomeAssistant from version 2022.6.7 because everything worked perfectly before.

Does anyone have this combination of Emulated HUE Bridge and Busch Jäger free@home working successfully?
I would like to try other things that lead to success.

Hey @Cavekeeper,

I’m using the exact same setup to connect FAH and HA. I had to downgrade in order to bring Hue integration back to work – did you manage to sort it out somehow?

Thanks in advance and have a good one.

No, unfortunately I have not yet found a solution to the problem. For this reason, I use the HA version 2022.6.7 and I am no longer updating. At the same time, I tried some newer versions on my HA testboard. Unfortunately, always without success. I had hoped that a developer could help on GitHub. But that looks bad. I also contacted the developers of BJ. Unfortunately, they do not support this topic (Emulated HUE). Unfortunately, I don’t know what to do at the moment.

Hm, that is bad as you got quite far from an investigation point of view. I would say we need to hope that there is someone fixing is this bug in one of the upcoming releases. I’m also looking forward to a version of the F@H integration which would use the local SysAP api which should be much more stable. Also the “virtual devices” functionality seems to offer a good way to connect both systems more reliable.

Yes, that’s right. A local SysAp API and the virtual devices would probably be a better choice. Unfortunately I still have the F@H V1. Unfortunately, this is not possible with this older hardware. You would have to convert to the V2 to get this functionality.

My latest findings are that it still doesn’t work with the HA Core 2022.12.3 version either. I just tested it again. That is to say, it only works in one direction. From BJ F@H towards HA I can set the emulated HUE switch. But not the other way around. In this respect, there is no feedback from HA that the switch has been set. In my opinion, this is still a problem with Homeassistant because the firmware from BJ F@H has not been changed since then. I also don’t think that the development team at HA is even aware of this particular problem and might be able to fix it. That would be desirable, because then you could also use the latest features of HA.

Hi,

I have exactly the same problem but finally I get it to work!!

My use-case is that I wanted to have a “switch” on my F@H-panel with which I want to trigger an automation in HA.

So I created in HA an input_boolean. This triggers an automation based on if it is on or off.
In F@H I created a virtual device as “SwitchingActuator” through the Rest-API and placed it in the relevant room.
To couple these two items together I use the addon Node-Red in HA:

  • Listening to the websocket of F@H to get modifications of the virtual device and update the entity in HA
  • Listening to state-changes in HA and update the virtual device in F@H through the Rest-API

Hi @derjoerg
May I ask you on which type of F@H you have programmed the virtual switch?
I remember that the V2 is required.
I don’t think that’s possible with the V1 system.

Yes, you are right. I have a v2.

I don’t know the behavior of v1.

Sorry

I can confirm that the issue has been resolved with version 2023.2.3. Emulated HUE is working again. Many thanks to the developers in particular @bdraco

Hi everyone, just writing here to avoid starting a new thread. Since updating the SysAP firmware to 3.2.0, the Emulated Hue Integration unfortunately doesn’t work for me anymore.
I haven’t made any other changes. Does anyone have the same issue? Is there a possible solution? The SysAP no longer recognizes the Emulated Hue. Only the physical Hue Bridge is being detected.

Maybe there is a way to downgrade the SysAP Firmware?

So for anyone landing here looking for a way to make your devices in homeassistant available in the free@home system, especially across different VLANs:

I have tried to get the emulated_hue included in HA running and failed.
My BJ SysAP is running in a different VLAN than my HA and the SysAP did not find the emulated_hue

I found a solution though. I wanted to set up a raspi with diyhue in the IoT VLAN and linking it to HA in the hopes that this would “just work” because then SysAP and the hue bridge are in the same network.

Just to try I installed the diyhue HA add-on. This just worked! Even across VLANs!

So I saved myself another PI running and doing simple stuff :smiley:

Only downside: I do not think devices other than lights are working this way right now.

Here are some links to get you started:
HA add-on: GitHub - diyhue/hassio-addon
Install instructions: Getting Started — diyHue 1.0 documentation
(they seem to be bit out of date. I was able to do everything in the UI, apart from including individual lights)