Request humidity on startup. #710

Activity

1. GreenGrassBlueOcean commented on Oct 14, 2026

   

   GreenGrassBlueOcean

   on Oct 14, 2026

   Contributor

   More actions

   Thanks for reporting this @lyubomirtraykov!

   We have opened #712 implementing your second (more elegant) suggestion:

   • When a climate zone reports humidity (*#4*<zone>*60*<humidity>##), or when Home Assistant restarts and restores a climate entity that previously had current_humidity in its state attributes (or has humidity: true configured), the zone remembers that it supports humidity (_humidity = True) and restores the last known current_humidity.
   • On startup (once the initial discovery sweep finishes), only climate zones with _humidity = True send a targeted *#4*<zone>*60## status request — even on physical gateways like the F461 where dimensionless *#4*<zone>## polling is skipped.

   ---

   Request for Bus Traces (for #710 / #712 and other open Climate PRs)

   Since you have an F461 gateway with standalone humidity/fancoil climate zones, could you share a few bus captures (via the MyHOME Bus Monitor card export or integration Diagnostics download) if you have a moment? We currently have several open climate PRs/issues waiting for real-hardware traces:

   1. Humidity queries (Request humidity on startup. #710 / feat(climate): remember zone humidity support and query dimension 60 on startup (#710) #712):
      • A trace showing the reply on the bus when sending *#4*0*60## (general humidity request) and *#4*<zone>*60## (point-to-point request for one of your humidity-capable zones, e.g. *#4*1*60##) via myhome.send_message (or on startup with feat(climate): remember zone humidity support and query dimension 60 on startup (#710) #712).
   2. Standalone vs #-prefixed setpoint writes (Setting a zone's target temperature fails on a 99-zone central plant: zone is addressed as *#4*3*#14*... instead of `*#4*#3*#14* #697):
      • In Setting a zone's target temperature fails on a 99-zone central plant: zone is addressed as *#4*3*#14*... instead of `*#4*#3*#14* #697 we are verifying how standalone thermostats behave with *#4*<zone>*#14*<TTTT>*3## (without # before the zone number) vs *#4*#<zone>*#14*<TTTT>*3## (with # before the zone number, which 99-zone central units require).
      • Could you capture a trace on your F461 when:
        • Sending *#4*1*#14*0215*3## (without #1), and
        • Sending *#4*#1*#14*0220*3## (with #1)
          via myhome.send_message, so we can see whether your standalone thermostat answers both or only the un-hashed *#4*1*#14*...## form?
   3. Open climate mode / season / programme PRs ([BLOCKED: PENDING TRACES] test: accept the OWNd#88 holiday readings for 13xxx/23xxx #650, Climate: show antifreeze (102) and thermal protection (202) of the central unit instead of both as off #699, OpenWebNet-HA/OWNd#97):
      • If you switch a thermostat on the wall (or via its native app) between Heating / Cooling / Off / Auto (Programme) / Manual (or holiday/vacation mode if supported), a bus trace of the emitted *4*...## and *#4*...## frames would be hugely helpful to validate our open climate PRs.

   Thanks again for your help!
2. GreenGrassBlueOcean

   added a commit that references this issue on Oct 14, 2026

   Merge pull request #712 from OpenWebNet-HA/feat/climate-startup-humid…

   ...

   1c131e0
3. GreenGrassBlueOcean

   closed this as completedon Oct 14, 2026