Update 5.200 Latest Topics

Why Yubii Geofencing Doesn’t Work on Android 16

Sun, 25 Jan 2026 00:41:23 +0000

After testing and checking all permissions, battery settings, and HC3 configuration, I found the actual reason geofencing is not working on my phone (Android 16):

Android 16 introduces a new background‑location and geofence API. The current Yubii Android app has not been updated to support this new API.

Because of this, Android 16 simply ignores the geofence registration request from the Yubii app. As a result:

Yubii never appears in “recent location access”
Geofence events never trigger
Mock location changes are ignored (while Alexa, Google home, Google Maps and Waze are reacting to the changes)
Real movement does nothing
HC3 scenes based on “enter/leave area” never run

This is not a permissions issue or a phone configuration issue — it’s a compatibility issue between Android 16 and the current Yubii app.

Until Fibaro updates the app to support the new Android 16 geofencing model, geofence‑based presence detection will not work on Android 16 devices.

Question:

Has anyone with Android 16 managed to get geofencing working successfully?

[SOLVED]Can't login after reset

Sun, 12 Apr 2026 10:16:21 +0000

My mistake, I found the password

Hi,

I have Factory reset my HC3 and it is asking me for user and password, and admin admin doesn't work?

How can I accss it now?

Update to 5.200.13 is causing issues with Elero shutters

Sun, 01 Feb 2026 21:22:03 +0000

Hi everyone,

Approx. 1 week after installing the hotfix version, I am seeing issues that the HC3 will not operate the Elero shutters motors anymore (Revoline RolTop-868).

No controls work. No up, no down, no associated scenes, etc. although the devices show online/green.

I have already tried to restart the HC3 and synchronize the elero devices (centrally and individually). The shutters do work, as I can still operate them with the regular remotes.

Does anyone have an idea what else to do?

Many thanks,

Stony

Alexa does not discover new devices on HC3 v5.200.13

Tue, 03 Mar 2026 19:32:42 +0000

Hi all,

I would like to ask if I am the only one observing this. Recently added devices (both Z-Wave and ZigBee) on my HC3 running SW version 5.200.13 are not discovered by Alexa anymore. The devices that are already present on Alexa are running fine (although a bit slower/with a bigger delay than a month or so back). But new devices don’t appear on the Alexa app even though I waited for a couple of days. I have not tried disabling the integration yet, though.

I can’t say when this happened, since it’s been some time since the previous time I added new devices. But this was definitely working - back then the devices appeared on the Alexa app literally in minutes, automatically. This is not true today, unfortunately.

Am I the only one with this issue? Or am I doing something wrong?

Thanks in advance!

HC3 bricked after 5.200 update

Tue, 17 Feb 2026 02:48:34 +0000

I am having a lot of issues after upgrading a new unit to 5.200
Takes forever to boot up and stays a very long time at "Starting Services" then reboots in Recovery Mode.

None of options there fixed anything, not even Factory Reset - I tried it twice and no fix - still booting in Recovery Mode.

What is going on?

Thank you

QuickApp crashed with hub.alert('simplePush'

Tue, 13 Jan 2026 23:35:17 +0000

Hello,
I have updated my HC3 FW 5.190.39 -> 5.200.8 this day and I am facing an issue mentioned on

			hub.alert('simplePush', OneMobile,'['..currentFullTime..']'..myMsg, false, '')
		
[14.01.2026] [00:32:01] [ERROR] [QUICKAPP1768]: QuickApp crashed
[14.01.2026] [00:32:01] [ERROR] [QUICKAPP1768]: main.lua:61: Wrong parameter type, string required. Provided param 'false' is type of boolean

		This function is shared in all my QA and Scene, how can we proceed to a Stable updated by having those changes in basing functions ... ?

		Have you a fix to provide or a documentation about this function ?

Looks like existing associations are not visible.

Sun, 01 Feb 2026 18:34:14 +0000

It appears that the associations only show 1 line.

Existing or newly added associations do not seem to appear.

Existing associations does seem to work.

Bug? Or is it me?

rgds Jeroen

Critical heating logic issue – boiler does not start according to schedule

Wed, 14 Jan 2026 20:50:47 +0000

After updating to version 5.200.8, a serious issue with the heating logic based on schedules and Fibaro thermostatic heads is still present.

Problem description (key issue):

A Climate Zone schedule is set to a target temperature, e.g. 21.5°C
The thermostatic head:
- has a local setpoint of e.g. 20.0°C
- does not automatically synchronize with the schedule
In this situation:
- the boiler does NOT start, even though the schedule requires 21.5°C
- the boiler starts only when the actual temperature drops below the local head setpoint (20.0°C)

Manual synchronization (important):

To temporarily restore correct behavior, it is necessary to manually force synchronization from the web interface (HC3), for example by:
- manually changing the temperature on the thermostatic head
- switching back to automatic / schedule mode
This synchronization:
- works only temporarily
- after a few minutes, or after the next wake-up of the device
- the thermostatic head becomes desynchronized again from the schedule

Impact:

The Climate Zone schedule does not actually control heating
The system decides whether to start the boiler based on the local setpoint of the thermostatic head, not the scheduled temperature
This leads to situations where:
- heating does not start despite scheduled demand
- thermal comfort is not maintained
- the user interface suggests the schedule is active, while in reality it is not

Additional observations:

The issue frequently occurs:
- after charging the thermostatic head
- after communication loss / wake-up
- after manual temperature changes followed by a return to automatic mode
This is not a UI issue — the decision logic of the system is inconsistent
The only workaround is:
- repeated manual synchronization
- or the use of additional LUA scenes (which should not be required when using schedules)

Conclusions:

The Climate Zone schedule does not enforce a persistent update of the head setpoint
Manually forced synchronization is not preserved over time
Boiler start logic is based on the local thermostatic head setpoint, not the scheduled temperature
This is a functional defect, not a configuration issue

Please advise:

whether this issue is known to the development team
whether a fix is planned where:
- the Climate Zone schedule is authoritative over thermostatic head setpoints
- and synchronization is persistent, not temporary

This is a core heating function, and the current behavior causes real-world usability and comfort issues.

Geofence is not working

Fri, 16 Jan 2026 01:43:53 +0000

This update still doesn't fix the geofence issue.

After the update 5.200.13, the 'self.logLevel' variable no longer works.

Fri, 16 Jan 2026 15:17:34 +0000

After the update 5.200.13, the 'self.logLevel' variable no longer works.

Crucial changes for API, scenes and QuickApps

Mon, 19 Jan 2026 10:24:39 +0000

Dear users,

Here are the key changes in API, scenes and QuickApp that the new version offers.

1. Added an option to define title to email notifications called from Lua (Quick Apps and scenes).

The email subject could be customized by adding an optional parameter to the method for sending an email to users:

In case of LUA Scenes: