{
    "packageName": "Shelly Plug US Gen4 (Zigbee)",
    "author": "Chris Busch",
    "version": "1.5.2",
    "minimumHEVersion": "2.3.0",
    "dateReleased": "2026-10-21",
    "documentationLink": "https://github.com/chsbusch-dot/hubitat-shelly-gen4-zigbee/blob/main/README.md",
    "communityLink": "https://community.hubitat.com/t/release-shelly-plug-us-gen4-zigbee-driver-plug-reported-units-no-relay-toggle-on-configure/166960",
    "licenseFile": "https://raw.githubusercontent.com/chsbusch-dot/hubitat-shelly-gen4-zigbee/main/LICENSE",
    "releaseNotes": "1.5.2 - The overpower cutoff (Switch off above, W) now defaults to 1800 W, the plug's maximum and its own default, so a new install shows the limit the plug runs at and sends it on the first save. Clearing the field still keeps the plug's own setting. Plugs that already store a limit are not changed.\n\n1.5.1 - Fixes from a review of 1.5.0. An off by the auto-off timer is judged from the latest switch-on (the plug restarts its timer on every on, a repeated one included) and the delay the plug had accepted at that moment, and only within a few seconds of the time it was due, so an off right after a repeated on, or long after the timer was due, counts as a trip. The auto-off delay, the current limit and the voltage limit now outlive Configure like the power limit, and a trip is judged against the current and voltage limits too. A voltage limit within 5% of the mains is held back, since a normal swing would trip it, and one outside 100 to 300 V is clamped. wifiOff waits for a Wi-Fi setup that is staged as well as one being sent, and the Wi-Fi state is read back after a refused or unconfirmed wifiOff as well.\n\n1.5.0 - New plug settings: an auto-off timer (the plug switches itself off a set number of seconds after each switch-on, which is the one to use for a heater), a current limit and a voltage limit. Each limit is checked against the plug's latest reading before it goes out, like the power limit. New wifiOff command: turns the plug's Wi-Fi off again after a firmware update, which until now took the plug's own web page. An off by the auto-off timer is logged, not counted as a trip.\n\n1.4.6 - A trip is still counted when the plug's only power report of the cycle arrived before the switch-on itself, or when the switch-on report was lost: the newest reading of the current reporting period counts as the cycle's load.\n\n1.4.5 - Fixes from a fifth review. Settings requests now use ids 1 to 9, so the cut-short reply opening always shows whether the plug accepted or refused; a reply judged from its tail needs the exact length of its own success. A trip counts only the load since the plug was last switched on, and right after an update from 1.4.3 the last reading still counts. Configure and Save keep a cutoff that was confirmed under 1.4.3. A Wi-Fi setup that is still being acknowledged is no longer dropped after 60 seconds.\n\n1.4.4 - Fixes from a fourth review. The overpower cutoff is checked again before every chunk of the write and needs a power reading from the current reporting period, so an old reading or a load that rose mid-write no longer lets it through. A preference saved while the previous write was still out is sent instead of being skipped with it. Configure keeps the cutoff the plug confirmed, so trips are still judged against it. Two 0 W reports before the plug switches itself off still count as a trip. Replies to settings are judged by their opening and no longer by a late tail of the previous reply, and a reply whose length arrives last is still judged. Bluetooth off now clears the field current firmware honours. A refusal of the power-on write by default response falls back to Shelly's channel. Wi-Fi reads are sent by the driver itself, so a setup waits the full quiet window, and each Wi-Fi write gets its own 30 seconds.\n\n1.4.3 - Trips are judged on the plug's recent load and the cutoff it confirmed, not on an old peak or a refused setting. A cutoff is sent only with a power reading taken since the plug was last switched on, measured in the plug's own watts. A reply to an earlier setting can no longer confirm the next one. Answers to reads are no longer taken as refused writes, a slow settings write is not restarted while it progresses, and an invalid switch report is ignored.\n\n1.4.2 - A plug that reports 0 W right before it switches itself off is still counted as a trip. A stale Wi-Fi error can no longer cancel a setup that has not started yet.\n\n1.4.1 - Fixes from a second review. The overpower cutoff is checked against the plug's current draw before every attempt, and a cutoff below the plug's maximum waits until the plug has reported its draw. Wi-Fi setup waits for a quiet channel and ignores stray acknowledgements, and an empty password now clears the stored one. A feature the plug reports late still gets its reporting. A refused power-on write stays on the fallback path. A trip under load looks at the recent load, not an old peak. A firmware change probes the optional features again. Network names with accents read back correctly.\n\n1.4.0 - The plug's LED ring can be set from Hubitat: its mode (a colour that follows the power draw, one colour when on and another when off, or off), the colours and brightness, and a night mode with its hours. Also: button presses are no longer counted as trips, a setting write that never finished no longer blocks later ones, a firmware change is noticed once, and Configure clears the Bluetooth attribute.\n\n1.3.2 - A plug setting the plug accepted is no longer reported as unconfirmed when the hub cuts the reply at an unlucky spot, which happened from the tenth setting sent to a plug onward.\n\n1.3.1 - setWifi works on the plug now: 1.3.0 also wrote the DHCP setting, which the plug treats as read-only, so it refused the whole setup. The Wi-Fi address shows none while the plug has no address (it reports 0.0.0.0 then). New wifiNetwork attribute: the network the plug is set to join.\n\n1.3.0 - New setWifi command, with wifiStatus and wifiIp. In Zigbee mode the plug still fetches firmware updates over Wi-Fi; setWifi gives it a network straight from Hubitat, without the Shelly app. The password goes to the plug only; the driver does not log or keep it. The relay is not touched.\n\n1.2.0 - New setBluetooth command. In Zigbee mode the Shelly app can reach the plug only over Bluetooth, for example to give it Wi-Fi for a firmware update; this turns Bluetooth on or off from Hubitat. The relay is not touched. Settings sent to the plug (Bluetooth, power-on state, overpower cutoff) now arrive intact on a busy mesh, a write that gets no answer is sent once more, and an error from the plug is reported as one.\n\n1.1.0 - New: an identify command that blinks the plug's LED; the light level from the plug's light sensor (firmware 2.0.1); trip detection, so a rule can see when the plug switches itself off under too much load; and two plug settings, what the plug does after a power cut and its overpower cutoff, sent only when you set them. Power factor shows up on firmware that offers it.\n\n1.0.1 - The health check no longer marks an idle plug offline by mistake. A plug with nothing to report can stay quiet for over half an hour while still reachable, so after three silent reporting periods the driver now asks the plug for its switch state and marks it offline only if that goes unanswered for a minute.\n\n1.0.0 - First release. Switch, power, energy, voltage, current and AC frequency for the Shelly Plug US Gen4 in Zigbee mode. Readings are scaled with the multiplier and divisor the plug reports, so power shows in watts and current in amps on firmware that changed its units. Every attribute of a bundled report is read, so power no longer freezes while current updates. Configure never switches the relay. Moving a plug from the Shelly 1PM Gen 4 driver removes that driver's calibration settings, which would now be wrong.",
    "drivers": [
        {
            "id": "9b1a0cd7-1fe3-45c1-9aef-53e00937d977",
            "name": "Shelly Plug US Gen4 (Zigbee)",
            "namespace": "chsbusch-dot",
            "location": "https://raw.githubusercontent.com/chsbusch-dot/hubitat-shelly-gen4-zigbee/main/drivers/Shelly-Plug-US-Gen4-Zigbee.groovy",
            "required": true
        }
    ]
}