[openwebnet] Dimmer ON/OFF via physical/MyHOME switch sends unsupported "DIM: 4" frame, state not updated in openHAB

### Describe the bug When a BTicino/Legrand dimmer (BUS) is switched fully ON or OFF (either via the physical switch or via the BTicino MyHOME app/MyHOME_Suite), the actuator sends a status frame with **DIM type 4**, which is not handled by openwebnet4j. As a result, the dimmer's Brightness item in openHAB never reflects the new state, and this is then never shown correctly in any openHAB-based UI (e.g. iPhone Kiosk / HABPanel). Note: this only affects full ON/OFF actions. **Dimming to an intermediate value (e.g. sliding to 47%) works correctly** and is reported normally via ItemStateChangedEvent. The bug is specific to the ON/OFF action path. Command direction (openHAB → BTicino) is not affected: switching the dimmer on/off from openHAB works correctly and is reflected immediately in MyHOME. ### Steps to reproduce 1. Add a BTicino BUS dimmer Thing (openwebnet:bus_dimmer) with a Brightness channel. 2. From the physical switch, or from the BTicino MyHOME app, dim the light to an intermediate value (e.g. 50%). - Expected: openHAB Brightness item updates correctly. **Actual: works as expected.** 3. From the physical switch, or from the BTicino MyHOME app, fully switch the dimmer OFF (or ON). - Expected: openHAB Brightness item updates to 0 (or last known brightness). - Actual: openHAB item state is not updated. The following appears in the log: ``` WARN ...enwebnet4j.message.BaseOpenMessage Unsupported DIM: 4 - frame *#1*0714*4*110*2## WARN ...rnal.handler.OpenWebNetLightingHandler updateBrightness() Cannot handle message `*#1*0714*4*110*2##` for thing openwebnet:bus_dimmer:... ``` ### Logs ``` 10:23:37.662 WARN ...enwebnet4j.message.BaseOpenMessage Unsupported DIM: 4 - frame *#1*0714*4*110*2## 10:23:37.663 WARN ...rnal.handler.OpenWebNetLightingHandler updateBrightness() Cannot handle message `*#1*0714*4*110*2##` for thing openwebnet:bus_dimmer:... 10:23:41.222 WARN ...enwebnet4j.message.BaseOpenMessage Unsupported DIM: 4 - frame *#1*0714*4*100*2## 10:23:41.223 WARN ...rnal.handler.OpenWebNetLightingHandler updateBrightness() Cannot handle message `*#1*0714*4*100*2##` for thing openwebnet:bus_dimmer:... 10:24:04.634 INFO openhab.event.ItemStateChangedEvent Item 'Woonkamer_beeld_TV' changed from 100 to 47 (source: org.openhab.core.thing$openwebnet:...) 10:24:10.505 INFO openhab.event.ItemStateChangedEvent Item 'Woonkamer_beeld_TV' changed from 47 to 73 (source: org.openhab.core.thing$openwebnet:...) 10:24:13.022 INFO openhab.event.ItemStateChangedEvent Item 'Woonkamer_beeld_TV' changed from 73 to 28 (source: org.openhab.core.thing$openwebnet:...) 10:24:17.490 WARN ...enwebnet4j.message.BaseOpenMessage Unsupported DIM: 4 - frame *#1*0715*4*100*2## 10:24:17.491 WARN ...rnal.handler.OpenWebNetLightingHandler updateBrightness() Cannot handle message `*#1*0715*4*100*2##` for thing openwebnet:bus_dimmer:... ``` I also confirmed sending a REFRESH command to the item does not work around the issue: the binding's dimension request to the bus is answered with the same unsupported DIM:4 frame. ### Expected behavior DIM:4 status frames sent on full ON/OFF should be parsed (or at minimum mapped to an ON/OFF or 0%/last-known-brightness state update) so the item state stays in sync with the actual device state. ### Environment - openHAB version: latest (please fill in exact version, e.g. via Settings > About) - OpenWebNet binding version: latest (bundled with above) - Gateway: BUS Gateway (openwebnet:bus_gateway) - Affected Things: openwebnet:bus_dimmer (tested on multiple WHERE addresses: 0013, 0014, 0713, 0714, 0715) - Dimmer actuators: BTicino F411/2 (or fill in your exact model) ### Additional context This appears to be the same underlying parsing limitation referenced for "Unsupported DIM" warnings elsewhere in the binding: DIM=4 is presumably a fade/speed-related dimension that openwebnet4j's BaseOpenMessage / Dim parsing does not currently recognize for WHO=1 (Lighting) dimmer status frames, unlike DIM=1 (brightness level) which is handled correctly. Happy to provide additional logs, full debug trace, or test a patched build if useful.