Roller Version 10 firmware not well handled

peterdey commented 3 years ago

I’ve got six blinds with hardwired rollers (no battery), but with varying firmware levels. Rollers with firmware version 12 and 22 work great!

Version 10 has a few deficiencies that aren’t handled well in aiopulse2:

This firmware can’t report the position (e.g. Blind ID 222 in the telnet protocol: !222r?; always reports !222Esh,<signal>;)
The “ol” (online) parameter in the web response often just reports “false”, even if the blind is actually available -- you can still send commands to it, and it will act on them. The Automate app even says for these blinds: Your motor appears to be offline. Try adjusting the % to see if the motor moves.

Sanitised debug log attached. ha-aiopulse2.log I have amended the log with comments for when I have initiated various actions for a blind that is reporting as Offline (ORS). Note: I have edited devices.py:298 to always return True, in order to be able to send the commands and capture the results in the attached (otherwise I would not be able to interact with this blind).

sillyfrog commented 3 years ago

Thanks for the info. What can you tell me about your blinds? Are they all plugin/mains operated (and any other features, or are they just roller blinds)? The "type" in the vo field is not something that's documented (not that the documentation for the aiopulse2 is official), specifically the U in 0.0U10. See the end of const.py for the (currently) known types. I'm thinking adding to that list would be something worth doing. Maybe the combo of the U type and version <= 10 may be all we need to ignore the ol parameter and always report as online.

This will also be a good test as I'll not create the battery entity if it's mains powered.

Finally, does HA ever report it as online? (If you click on the entity in the HA UI and look at the history, that's the easiest way.)

Cheers (PS: I'm also relearning this code - it's been a while - so I'm going a bit slow :) )

peterdey commented 3 years ago

All units are roller blinds (tubular motors), 240V AC, plugin to mains. I'm not aware of any "other" features (e.g. no "tilt" function).

For completeness:	Identifier	Model	Reported Firmware
`PM4`	Acmeda Automate E6	10	30 October 2018
`ORS`	Acmeda Automate E6	10	30 October 2018
`J0Q`	Acmeda Automate E6	10	30 October 2018
`TLQ`	Acmeda Automate E6	10	30 October 2018
`QUG`	Acmeda Automate E6	12	30 October 2018
`4U2`	Maxismart 6/28	22	9 July 2020

"Model" is exactly as on the supplier's invoice
"Maxismart 6/28" appears to perhaps be a re-branded Acmeda (or perhaps Dooya) tubular motor. I suspect it's the Acmeda one, based on the colour & style of the pairing button.

Strangely, the rollers with versions 10 and 12 were all supplied on the same date. A visual inspection doesn't reveal any obvious differences. The style of the pairing button on TLQ appears slightly different to the others (embossed instead of recessed).

HA does report the entity as online, typically after a command has been transmitted to the roller. It seems to go back to offline after some period (between 40 seconds and 3 minutes - not consistently reproducible).

sillyfrog commented 3 years ago

@peterdey Quick one, does HA show the rollers has having batteries at the moment? I have noticed that I think it will (just None), so have addressed that in the release I have just put out (v0.6.0).

There is some new stuff for the HA side as well, you can get that here: https://github.com/sillyfrog/automate-ha-dev/ (Just install it over the top of what you currently have).

This should address the "Offline" issue for older rollers (v12 and below), and not add the battery entity if the device does not have batteries (you may need to remove the integration and re-add to clean up HA).

Let me know how you go :)

peterdey commented 3 years ago

Yep, new version worked great! I've installed both the new version of the integration and the aiopulse2 library.

You're correct; v0.5.9 showed rollers as having batteries; but I think the battery entities all just reported "Unavailable". Updated and re-added the integration; and the battery entity has now (correctly) not been added.

Position slider and cover.set_cover_position now both work perfectly.
Stop button works perfectly.
Small issue with the Up and Down buttons (see below)
Signal entity works correctly (was never an issue; including for completeness).

There's only a few niggly issues with the Up & Down buttons, and I suspect this is an issue with HA, not with the integration or library:

Start conditions: Roller physically in top position: Up button unavailable; Stop & Down both available.
Press "Down" button. Roller starts moving down; Down button becomes unavailable; Up becomes available.
Press "Stop" button. Down button doesn't become available again.

Sometimes both the "Up" and "Down" buttons are unavailable, but I haven't been able to consistently reproduce this.

I say niggly, because I'm happy to just have my automations use cover.set_cover_position.

Similarly, on a fresh HA restart, HA doesn't know the position of the blinds - so HA always thinks they start off Open, and the Up button is unavailable.

I think you can drop ONLINE_MIN_VERSION to 12 - My v12 blind seems to correctly report ol = True.

sillyfrog commented 3 years ago

Thanks for the update. Sounds like we are getting close :)

I have changed the ONLINE_MIN_VERSION to 11 (I have not seen any reports of that version, but hey, will leave it there for now).

Re the buttons - that's a bit odd and confusing. I have just done a quick check with mine (I'm running HA 2021.2.3), and it appears to work (even if it took a second or two for the buttons to enable again). What version HA are you running? When you click on the device in the Lovelace UI, does it show the correct percentage open/closed? (It's only updated after the blind has stopped, so may take a second to update after changing).

Cheers.

peterdey commented 3 years ago

Ah, sorry - I should have clarified - the strange behaviour with the Up & Down buttons only occurs for the Version 10 rollers (i.e. the ones that don't report their position). The Version 12 roller works exactly as you've described.

I'm running HA version 2021.2.3.

peterdey commented 3 years ago

Applied the patch in https://github.com/sillyfrog/aiopulse2/issues/4#issuecomment-785471171

Some v10 rollers (not all) are still having issues with the Up/Down buttons.

Steps to get to the screenshot below (note: not reproducible! And not always the same rollers...):

Blind physical position: 100 (i.e. open)
HA fresh restart
Activated scene which set current_position on cover.lh_sheer to 0

Observations:

Up and Down buttons are disabled (might not be obvious due to the theme...)
Position is 100 (not that this matters, since this version 10 roller doesn't report position)
Calling service cover.open_cover (entity_id: cover.lh_sheer) - Works
Calling service cover.set_cover_position (entity_id: cover.lh_blockout) - Works (this one had the same issue)
Activating the scene isn't necessarily required - but was done to eliminate any starting state assumptions. For some rollers, even on a clean HA boot, both buttons are disabled.

sillyfrog commented 3 years ago

To clarify, the buttons become disabled after a restart, or after activating the scene (or it's still kind of random)?

Reporting None means the position is unknown - so maybe HA is taking a worst case scenario - I'm hoping if we default to an integer we'll at least get something enabled.

sillyfrog commented 3 years ago

Further to the above, I think that'll help looking into the HA code. Try this change (it's a partial diff - I can commit and push if easier):

@@ -329,9 +330,12 @@ class Hub:
                     newvals["version"] = batteryinfo.group("version")

             try:
-                version = int(newvals.get("version") or self.rollers[rollerid].version)
+                version = int(
+                    newvals.get("version") or forcetoint(self.rollers[rollerid].version)
+                )
                 if version < ONLINE_MIN_VERSION:
                     newvals["online"] = True
+                    newvals["closed_percent"] = 50
             except Exception:
                 pass

(More accurate in that it only applies the value to the older rollers - the only change from what you have is the newvals["closed_percent"] = 50 line)

peterdey commented 3 years ago

Sorry for the delay, I've been trying to figure out if there's any pattern to when the particular buttons become available (or not).

Patch applied fine, seems to have made it a little bit more usable, but it's still a bit inconsistent.

The problem seems to come down to that the HA API appears to require that the cover report it's position if the SUPPORT_SET_POSITION bit is set...

I wonder how the Template Cover platform gets around this in "Optmistic Mode"?

Anyway, the results of some investigations:

Cover (LH Blockout / cover.lh_blockout; firmware version 10, device ID PM4) physical position: Open/100
Fresh HA restart --> Up & Stop enabled; Down disabled Consistent; every restart.

0. Initial status from fresh restart

cover.lh_blockout
current_position: 50
friendly_name: LH Blockout
supported_features: 15
device_class: shade

1. cover.set_cover_position

(from fresh restart; state in 0)

entity_id: cover.lh_blockout
position: 50

Works

2. cover.open_cover

_After cover.set_cover_position in 1_

entity_id: cover.lh_blockout

Fails

3. cover.set_cover_position

entity_id: cover.lh_blockout
position: 100

Fails

4. cover.set_cover_position

entity_id: cover.lh_blockout
position: 90

Succeeds ... strangely

5. cover.set_cover_position

_After cover.set_cover_position in 4_

entity_id: cover.lh_blockout
position: 100

Succeeds

More strangeness

Fresh restart (0) ->1 -> 3 (skip 2) fails; next step (4) still succeeds.

Not sure if this helps at all. This seems to me more like a bug in HA than a bug in your integration?

I've also tried a terminal session direct with the hub at the points where HA doesn't seem to "work": Both !PM4o; (open) and !PM4m000; (set position to "0") work fine. I'm guessing HA just isn't sending the commands through to the hub, because it thinks it knows better?

sillyfrog commented 3 years ago

It's weird... I would have thought it would be working (just been doing more testing on mine).

Can you try getting some more logs please - you'll also need to add something like the following to get them all:

logger:
  default: info
  logs:
    aiopulse2: debug
    custom_components.automate: debug

And then repeat your tests. The one I'm looking for is something like:

2021-03-04 15:08:56 DEBUG (SyncWorker_13) [custom_components.automate.base] Device update notification received: 0R5 ('B1')

Another thought, can you also try replacing move_to with the following (in devices.py, line 523):

    async def move_to(self, percent: int):
        """Send command to move the roller to a percentage closed."""
        if forcetoint(self.version) < ONLINE_MIN_VERSION:
            self.closed_percent = percent
        else:
            currentpcg = self.closed_percent
            if currentpcg is None:
                currentpcg = 50
            if percent > currentpcg:
                self.action = MovingAction.down
            elif percent < currentpcg:
                self.action = MovingAction.up
            else:
                self.action = MovingAction.stopped
            self._moving = True
            self.target_closed_percent = percent
        self.notify_callback()
        await self.hub.send_payload(
            {
                "method": "shadow",
                "args": {
                    "desired": {"shades": {self.id: {"movePercent": int(percent)}}},
                    "timeStamp": time.time(),
                },
            }
        )

This should stop it telling HA that the roller is currently moving (which maybe the issue - just a guess).

sillyfrog commented 3 years ago

PS: Rather than trying to patch on patch, I have just pushed a progress commit of how things are looking at the moment, you can download directly from here: https://raw.githubusercontent.com/sillyfrog/aiopulse2/master/aiopulse2/devices.py

peterdey commented 3 years ago

For OCD reasons, I changed lines 338 and 530 from 50 (%) to 49 (%). In scripts and scenes, I would often specify for the blind to be "half open" (i.e. 50%).

I'm closing this issue, because I no longer have binds running the older firmware. I escalated the issue back to Acmeda, who found that they had a faulty batch of 20-30 "Automate E6" motors, which do not report their positions back to the hub. I've had all the the v10 firmware units replaced with v22 units under warranty.

sillyfrog / aiopulse2