@ljbotero, I’m getting the same error as @pomonabill220. I’m seeing it every one hour in my log fwiw, although I’m not seeing any problems manifest so far.
Error Monitor Harrogate II - Flair Vents - org.codehaus.groovy.runtime.metaclass.missingmethodexceptionnostack: no signature of method: java.lang.string.call() is applicable for argument types: (hubitat.scheduling.asyncresponse null) values: [hubitat.scheduling.asyncresponse@8d0565 null]
possible solutions: wait() chars() any() trim() grep() find() (handleauthresponse)
I just looked through my log after seeing your note about seeing it every one hour...
and i see it EVERY hour accurate to the SECOND in my log!
Interesting!
Thanks guys, I'm investigating this, I'm also seeing this in my logs, but it's quite tricky, I'll get back to you once I identify the root cause and will push an update once I figure this out.
Curious if either of you guys are seeing actual problems associated with this error? Versus are we possibly chasing an error strictly in theory not practice?
If I am having behavior problems, I’m not seeing it/them.
Just updated to 0.233.
A question just popped into my brain!
Since I use the thermostat controller HE app and not my physical stat for mode and setpoint status to your flair app, AND I use fractional setpoints (IE 75.5 deg F), does your flair app use the decimal values or round the numbers?
Also my temperature sensors that I use in my rooms report fractional values as well.
Would this cause problems?
@ljbotero, I had to disable your app because I was getting flooded with these errors (log below). I’m suspecting this may be unique to me as I have 3 instances running in parallel (one each for upstairs, ground level, and basement) since each is its own HVAC zone. This is happening only for the one zone where I have relatively many vents (21). But I never had this problem with prior versions, so maybe there is a fix I can try?
FWIW when I check “app stats” and “device stats” in the HE log, your integration doesn’t show up anywhere close to the top of the list in resource consumption, so I’m confused why it’s happening.
Temperature change 0.0°C is below hysteresis threshold 0.6°C - ignoring
is showing up so much? I know that the room temps are changing more than 0.6C.. more like 1-2 F.
Does this indicate that the temperature sensors are not being used?
I'm curious on how I can tweak this to work a bit better for me. I know that the code is written with the intention of minimizing vent movements and trying to find an overall balance. I'm kind of shooting for the opposite, I don't mind at all if there are frequent vent movements in order to achieve better balance in the house. The east side of the house is hot in the morning prompting the vents to open more, and then in the afternoon when the west side of the house is hot, I just don't feel like this is responsive enough. So the east side of the house overcools and the west side is left hot. Eventually it recovers but it just seems like it's a constant circle of trying to play catch up. I would much rather it monitor the temps and make vent adjustments in more real time.
Is there anything I can tweak in the parameters to make it run the calculations and make vent adjustments more often to promote better real time balancing?
@syhnthetik, I'm definitely not the expert on this integration (so I'll defer to the OP), but I don't have the impression that the dynamic balancing economizes on movement. I get adjustments as often -- or more often -- that is needed or practical for an HVAC system, But of course YMMV!
Not sure if you're a developer, but if you are, I'm pretty sure (subject to IP limitations) you can fork the code and go nuts adjusting the logic.
EDIT: But if you're asking whether the current app allows for you to set these parameters in the UI, I'm pretty sure the answer to that is NO, which is why you either have to DIY or make feature requests to the original developer.
@mluck thanks for the reply! There definitely is nothing in the UI. But there are a bunch of defined parameters at the beginning of the app code, some of them @ljbotero has recommended can be changed in certain scenarios. I'm far from a dev, so I was just hoping he could chime in to say if modifying one or more of those parameters might help the system be more reactive at the expense of increased battery drain from frequent vent movements.
If there's not, I totally understand, this is still AMAZING when compared to the native Flair control. I was just bored and looking to tinker
Ah yeah makes sense. If you’re a tinkerer, maybe ChatGPT could help you edit the code? I’ve never tried but I’ve heard a bunch of others around here do this successfully. Cheers.
@mluck thanks for the ChatGPT suggestion! It worked beautifully to make the changes I was looking for. I also went down a days-long rabbit hole and now know WAY more about groovy and gpt
Hello - switching over to this app/driver as the paid MY Flair - depreciated version started not working for me. I have all my own rules, programming and monitoring setup using webcore. Was primarily using previous app and drivers for control. I now have this app and drivers setup to control my 24 vents and 3 pucks. However, i am seeing a couple places were it may be possible to improve. Able to add Switch capability to the vents? I think this would also allow me to see the Vents as a Switch (with Level) in my Sharptools.io dashboard, but currently the devices do not seem to be available for use in sharptools. Second request - Battery status. Other app, i noticed we could see the vents battery status, so requested this added and it was added shortly after. Hoping it would be an easy add here to monitor the vents and flag when batteries are low and need changed. Thanks in advance and thanks for creating an alternative solution to get my HVAC system back online.
I’ll defer to the developer on your switch question, but regarding the batteries, that attribute is already included in the device driver. I know because I use it to monitor and notify on low battery.
Thanks, I use a simple app called Battery Monitor and the vents are not present to select when i configure this app to select which batteries to monitor. After your message i also checked a webcore piston I use to monitor battery status of devices. On the Vents i dont find an attribute for battery, but i do see Voltage. Assuming you are using the Voltage attribute and monitoring to flag if below a particular level? If battery level attribute is also available, then could use other native apps such as Battery Monitor, Sharptools.io battery monitor, etc.
Similar to some others, I am just now transitioning to this app from MyFlair due to deprecated status. However, after 48 hours of running the app, I am getting a lot of repeat errors on excessive hub load that I'm not sure how to resolve.
I am not using the dynamic balancing feature, just using the app to bring in my pucks and vents for control and monitoring via webcore. Any assistance/guidance would be much appreciated! Errors I'm seeing repeated constantly:
[app:1094]2025-10-21 06:24:01.976 PM[error]com.hubitat.app.exception.LimitExceededException: App 1094 generates excessive hub load on line 1821 (method handlePuckGetWithCache)
[app:1094]2025-10-21 06:21:56.275 PM[error]groovy.lang.MissingMethodException: No signature of method: user_app_bot_flair_Flair_Vents_202.logWarn() is applicable for argument types: (com.hubitat.app.exception.LimitExceededException) values: [com.hubitat.app.exception.LimitExceededException: App 1094 generates excessive hub load]
Possible solutions: login() on line 1939 (method handleVentPatch)
I am also here because yracine's MyFlair no longer receives updates from the puck/vents. I suspect that this is due to Flair's updates to the OAuth API, not sure but irritating. It appears that now the API keys have to be manually requested from Flair here, which is dumb.
