v0.4.0 – two-phase covers, CEN/CEN+ devices, wall pushbutton events

Three additions: a two-phase travel model for covers, CEN/CEN+ scenario controls as Home Assistant devices with UI-selectable triggers, and a bus event for wall pushbuttons in dimmer mode. Nothing is renamed and no entity_id or unique_id changes; the event-contract changes are additive (a new mac key on the CEN/CEN+ bus events, one new event). A myhome.yaml written for 0.3.x keeps behaving exactly as it did: the cover model and the scenario controls are opt-in through new keys.

Fixed

• Timed cover targets (set_cover_position, tilt) were cancelled by the gateway: MyHOMEServer1 answers a movement command with a "stopped" frame immediately followed by the "opening"/"closing" one, and that stop was taken as the end of the run, so the shutter ran to the end stop. The stop echo arriving within 1.5 s of our own command is now ignored; real stops (keypad) are still honoured. Found live on the first calibrated shutter.
• myhome.send_message crashed with an internal error on frames that OWNd's typed parser does not model, such as a CEN+ virtual press (*25*21#1*#2##, WHERE starting with #). Well-formed frames are now sent as generic commands; malformed ones raise a proper validation error. Found while testing the scenario controls.

Added

• Wall pushbutton events. The gateway echoes what a physical light pushbutton sent (*1*1000#WHAT*WHERE##) right before the actuator answers; those frames were dropped. They are now republished as myhome_light_pushbutton_event (mac, where, what, event, message). The point is dimmer-mode pushbuttons wired to relays: a hold sends dim_up/dim_down about twice a second and nothing else on the bus reflects it, so this is the only way to turn such a button into a dimming remote for, say, a Zigbee bulb. Short presses give on/off next to the status the entity already follows. Found on a bedside pushbutton.

• CEN / CEN+ scenario controls as devices, with device triggers and an event entity. A wall keypad has no state, so until now its presses existed only as myhome_cenplus_event / myhome_cen_event bus events, usable from YAML and invisible everywhere else. Declaring the control under the new scenario_control: block in myhome.yaml now creates a device on the gateway carrying one event entity (event.<name>_scenario_control, state = timestamp of the last press, attributes event_type, pushbutton, protocol, object/where) and a set of device triggers, so "Button 2 held down on Living Room Keypad" can be picked in the automation editor instead of hand-written event triggers. Both CEN+ (object, buttons 1-32, including the long-press repeat and the four rotary events) and CEN (where, buttons 0-31) are supported; buttons decides which combinations the picker offers, never what reaches the bus. Controls that are not declared keep firing the bus events and create nothing, exactly as in 0.3.x.

  The device-trigger module is ported from fedem95/MyHOME by fedem95 (AGPL-3.0): the base-schema extension, the type/subtype split and the delegation to Home Assistant's own event trigger are theirs; the concept was also explored by mantovanellimatteo/MyHOME. The event-entity model is ported from adrael/MyHOME by raphael (AGPL-3.0), whose event.py implements the same shape for a doorbell.

  See Configuration → Scenario control and Recipes → Device triggers and blueprints.

• mac in the myhome_cenplus_event / myhome_cen_event payloads. Additive: the existing object, pushbutton and event keys are untouched, so automations written before 0.4.0 keep matching. It carries the normalised MAC of the gateway that saw the frame, so a multi-gateway plant can tell two controls with the same object number apart — which is what the device triggers filter on. Suggested by fedem95, whose fork adds the same key.

• Two automation blueprints, in blueprints/automation/myhome/: cenplus_button_light.yaml (short press toggles a light, long press turns it off) and cenplus_button_cover.yaml (hold up/down to open/close a cover, short press to stop). HACS does not install blueprints, so they are imported by URL — see Recipes → Importing the blueprints.

• Two-phase travel model for basic covers (slat_time). On most roller shutters the motor run is not all lift: from fully closed the first seconds only tilt the slats ("lamelle") open while the curtain stays on the floor, and when closing the motor keeps running for the same few seconds after the curtain has touched the floor, to close them again. The linear 0-100 estimate therefore reported "5 %" with the curtain still on the floor, and set position 50 % from closed ended around 55-60 %. Declaring slat_time (seconds, default 0 = previous behaviour) splits every run into a slat phase and a curtain phase:

  • current_position now describes the curtain only — 0 = curtain on the floor whatever the slats do, 100 = fully open;
  • current_tilt_position describes the slats — 0 = closed, 100 = open — and the cover is closed only when both are 0;
  • the tilt services (cover.open_cover_tilt, cover.close_cover_tilt, cover.set_cover_tilt_position, cover.stop_cover_tilt) appear on covers with a slat_time, which makes "closed with the slats open" a single service call; above the floor the slats are always open, so tilt commands are ignored there;
  • cover.set_cover_position computes the run through both phases (from closed, 5 % costs slat_time + 0.05 × (opening_time - slat_time) seconds), and movements started from a physical keypad are tracked through the same model.

  See Configuration → The two-phase travel model and Recipes → Covers.

• Separate opening_time and closing_time for basic covers. Both default to shutter_run, which stays the one value most installations need; set them when the motor is measurably slower in one direction. The idea of separate up/down travel times comes from andrea-parisi/MyHOME.

• Basic covers expose Slat time, Opening time and Closing time as extra state attributes when those keys are in use, next to the existing Shutter run.

Changed

• cover.set_cover_position with a target of 0 or 100 now runs the cover into its end stop instead of stopping it with a timer at the computed moment. The end stop is what re-calibrates a time-based estimate, and the stop command was redundant there.
• The estimated tilt is persisted next to the position, so "closed with the slats open" survives a restart or a reload.