RFLink-cover 'stop' not working and inverted up/down with KAKU devices

WaaZaa666 commented 6 years ago

And mention @aequitas ;) Home Assistant release (hass --version): 0.58.1

Python release (python3 --version): 3.4

Component/platform: RFLink-Cover

Description of problem: When using the RFLink-cover component in combination with my KAKU ASUN-650, I am unable to use the stop button. Also, all commands are inverted.

Expected: Kaku Asun cover can be stopped by repeating the command sent. When the cover is sent the down command, resend down to stop. When the cover is sent the up command, resend up to stop.

Problem-relevant configuration.yaml entries and steps to reproduce:

cover:
  - platform: rflink
    devices:
      kaku_000043_2:
        name: Rolluik logeerkamer
      newkaku_00000064_2:
        name: Zonnescherm
      newkaku_0107a6f6_c:
        name: RolluikRaam
      newkaku_0107a6f6_b:
        name: RolluikDeur

Hit the up button
Hit the stop button

Additional info:

2017-11-26 15:28:56 DEBUG (MainThread) [homeassistant.components.rflink] Sending command: STOP to Rflink device: newkaku_00000064_2
2017-11-26 15:28:56 DEBUG (MainThread) [rflink.protocol] sending command: {'protocol': 'newkaku', 'id': '00000064', 'switch': '2', 'command': 'STOP'}
2017-11-26 15:28:56 DEBUG (MainThread) [rflink.protocol] writing data: '10;newkaku;00000064;2;STOP;\r\n'
2017-11-26 15:28:56 DEBUG (MainThread) [rflink.protocol] waiting for acknowledgement
2017-11-26 15:28:56 DEBUG (MainThread) [rflink.protocol] received data: 20;02;CMD UNKNOWN;
2017-11-26 15:28:56 DEBUG (MainThread) [rflink.protocol] got packet: 20;02;CMD UNKNOWN;
2017-11-26 15:28:56 DEBUG (MainThread) [rflink.protocol] decoded packet: {'node': 'gateway', 'protocol': 'unknown', 'response': 'command_unknown', 'ok': False}
2017-11-26 15:28:56 DEBUG (MainThread) [rflink.protocol] command response: {'node': 'gateway', 'protocol': 'unknown', 'response': 'command_unknown', 'ok': False}
2017-11-26 15:28:56 DEBUG (MainThread) [rflink.protocol] packet acknowledged

aequitas commented 6 years ago

Could you verify if sending the opposite command also works to stop? This might make implementation easier.

WaaZaa666 commented 6 years ago

Hi @aequitas, unfortunately, in order to stop the ASUN devices, you really need to send the same command again. Sending the opposite command, makes the shutter go back to its start position in the send direction.

If too hard to implement same command sending, hiding the stop button could be an option for me as well. This way at least our home users wont be confused...

Is inversion something that is possible?

aequitas commented 6 years ago

To bad, but should not be a big problem, we can remember the sent command if needed.

I dunno about hiding the stop button. Maybe the cover component and panel supports this but I would have to look into this.

balloobbot commented 6 years ago

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates.

Please make sure to update to the latest Home Assistant version and check if that solves the issue. Let us know if that works for you by adding a comment :+1:

aequitas commented 6 years ago

I currently don't have enough spare time to spend on HA/RFLink related tasks. If anyone wants to pick this up I might be able to assist.

balloobbot commented 6 years ago

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates.

Please make sure to update to the latest Home Assistant version and check if that solves the issue. Let us know if that works for you by adding a comment :+1:

Emacee commented 6 years ago

Hi! Today I installed a roller shutter with ASUN-650 as controller. I'm using this in conjunction with RFLink and hass.io. So far so good, however I'm facing the same issue as OP but I don't have the coding skills to fix this. This issue however, is still relevant!

fmartens commented 5 years ago

This is the only 'thread' mentioning the ASUN-650 so that is the reason why I am responding here.

I am migrating from Domoticz to Home Assistant and wanted the ASUN-650 to work properly without having to rewire them.

In RFLink, the ON and DOWN command are used to close the cover. The OFF and UP command are used to open the cover. The KAKU (COCO) ASUN-650 uses the ON command to open the cover and it uses the OFF command to close the cover.

I've introduced a configuration property named 'invert_up_down_command' that is used when the RflinkCommand class handles the 'close_cover' and 'open_cover' commands. The property only works for RFLink covers:

cover rflink:
  - platform: rflink
    device_defaults:
      fire_event: false
    devices:
      newkaku_00000001_d:
        name: livingroom
        invert_up_down_command: true
      newkaku_00000001_e:
        name: master_bedroom
        invert_up_down_command: true

The code changes are available at: https://github.com/fmartens/home-assistant/commit/1b34ce80cdc024d42c5eb0b56b6f1e474b2e46ee

I am not a Home Assistant expert and my Python skills are not that good but I've tested my solution and it works.

@aequitas: Sorry bothering you but your name comes up when RFLink is discussed. Do I need to do a pull request or is there something else I need to do first? Are you willing to glance at my solution and provide me some pointers?

@Emacee: Are you still looking for a solution? Are you willing to test my solution?

WaaZaa666 commented 5 years ago

@fmartens I actually still have the issue. Let me check how I can test this.

fmartens commented 5 years ago

@WaaZaa666 , that would be very nice, thank you for your offer.

I think you could overwrite the files after backing them up. The init.py goes into /srv/homeassistant/lib/python3.5/site-packages/homeassistant/components/rflink.py and the other one should go into /srv/homeassistant/lib/python3.5/site-packages/homeassistant/components/covers/rflink.py. I am not sure if you need to delete the entries from the pycache directories though.

I think I will implement the stop functionality this weekend because I dislike non-functional stop buttons :-) I will name the property repeat_up_down_command_to_stop.

Emacee commented 5 years ago

By creatimg a template cover I was able to fix the up/down problem. This solution seems nicer as it is integrated in the RFLink component. Especially a stop button would be nice as I’ve not been able to script something for that. I will try to test your component changes when I have the time to do so!

fmartens commented 5 years ago

Implementing the stop button for the ASUN-650 is undoable. You can store the last UP/DOWN command and repeat it when handling to stop_cover command but the problem is that when you click the UP/DOWN command twice, the cover is stopped and you should then not repeat the last command from the 'stop_cover' function because the cover will start moving again. The ASUN-650 does not report its state, so you don't know if the last command energized the motor or not. Assuming a state is unsafe.

You could change the property name to 'stop_repeats_last_up_down_command' and let the stop button repeat the last command disregarding the state but that is ugly. The user expects the cover to stop right?

@WaaZaa666, @Emacee and @aequitas : Do you have any thoughts on this?

fmartens commented 5 years ago

Hi all, I submitted a pull request for the invert part: https://github.com/home-assistant/home-assistant/pull/22842

fmartens commented 5 years ago

This is a continuation of the discussion between @javicalle and @fmartens to make the KAKU/COCO ASUN-650 work without the need to rewire them. The start of the discussion can be found at: #22842.

@javicalle, I haven't had the time to test your code yet because of other obligations but i will try tomorrow:

class InvertedRflinkCover(RflinkCover):
    """Rflink cover that has inverted open/close commands."""

    async def _async_send_command(self, cmd, repetitions):
        """Will invert only the OPEN/CLOSE commands."""
        _LOGGER.debug(
            "Getting command: %s for Rflink device: %s", cmd, self._device_id)
        if cmd == 'DOWN':
            cmmnd = 'UP'
        elif cmd == 'UP':
            cmmnd = 'DOWN'
        else:
            cmmnd = cmd

        await super()._async_send_command(cmmnd, repetitions)

Your implementation is way more elegant than my initial attempt in init.py and I see what you are trying to achieve.

fmartens commented 5 years ago

@javicalle, your code works, I really like it.

Trace for the open_cover command from home assistant:

2019-04-18 00:18:32 DEBUG (MainThread) [homeassistant.components.rflink.cover] Getting command: UP for Rflink device: newkaku_00xxxxxx_d
2019-04-18 00:18:32 DEBUG (MainThread) [homeassistant.components.rflink] Sending command: DOWN to Rflink device: newkaku_00xxxxxx_d
2019-04-18 00:18:32 DEBUG (MainThread) [rflink.protocol] sending command: {'switch': 'd', 'protocol': 'newkaku', 'id': '00xxxxxx', 'command': 'DOWN'}
2019-04-18 00:18:32 DEBUG (MainThread) [rflink.protocol] writing data: '10;newkaku;00xxxxxx;d;DOWN;\r\n'
2019-04-18 00:18:32 DEBUG (MainThread) [rflink.protocol] waiting for acknowledgement
2019-04-18 00:18:33 DEBUG (MainThread) [rflink.protocol] received data: 20;01;OK;
2019-04-18 00:18:33 DEBUG (MainThread) [rflink.protocol] got packet: 20;01;OK;
2019-04-18 00:18:33 DEBUG (MainThread) [rflink.protocol] decoded packet: {'ok': True, 'protocol': 'unknown', 'node': 'gateway'}
2019-04-18 00:18:33 DEBUG (MainThread) [rflink.protocol] command response: {'ok': True, 'protocol': 'unknown', 'node': 'gateway'}
2019-04-18 00:18:33 DEBUG (MainThread) [rflink.protocol] packet acknowledged

Trace for the 'ON' command from the remote.

2019-04-18 00:18:37 DEBUG (MainThread) [rflink.protocol] received data: 20;03;NewKaku;ID=00
2019-04-18 00:18:37 DEBUG (MainThread) [rflink.protocol] received data: xxxxxx;SWITCH=d;CMD=ON;
2019-04-18 00:18:37 DEBUG (MainThread) [rflink.protocol] received data: 
2019-04-18 00:18:37 DEBUG (MainThread) [rflink.protocol] got packet: 20;03;NewKaku;ID=00xxxxxx;SWITCH=d;CMD=ON;
2019-04-18 00:18:37 DEBUG (MainThread) [rflink.protocol] decoded packet: {'id': '00xxxxxx', 'switch': 'd', 'protocol': 'newkaku', 'node': 'gateway', 'command': 'on'}
2019-04-18 00:18:37 DEBUG (MainThread) [rflink.protocol] got event: {'command': 'on', 'id': 'newkaku_00xxxxxx_d'}
2019-04-18 00:18:37 DEBUG (MainThread) [homeassistant.components.rflink] event of type command: {'command': 'on', 'id': 'newkaku_00xxxxxx_d'}
2019-04-18 00:18:37 DEBUG (MainThread) [homeassistant.components.rflink] entity_ids: ['cover.woonkamer_voor']
2019-04-18 00:18:37 DEBUG (MainThread) [homeassistant.components.rflink] passing event to cover.woonkamer_voor

I will test the other direction tomorrow, I don't want to wake up the family :-)

@javicalle, do you want me to submit the stuff and go through the administrative process or is that something you would like to do?

fmartens commented 5 years ago

@javicalle , here are the traces when closing/lowering the cover. I am using your code btw.

Via home assistant:

2019-04-18 10:56:07 DEBUG (MainThread) [homeassistant.components.rflink.cover] Getting command: DOWN for Rflink device: newkaku_00xxxxxx_d
2019-04-18 10:56:07 DEBUG (MainThread) [homeassistant.components.rflink] Sending command: UP to Rflink device: newkaku_00xxxxxx_d
2019-04-18 10:56:07 DEBUG (MainThread) [rflink.protocol] sending command: {'switch': 'd', 'protocol': 'newkaku', 'id': '00xxxxxx', 'command': 'UP'}
2019-04-18 10:56:07 DEBUG (MainThread) [rflink.protocol] writing data: '10;newkaku;00xxxxxx;d;UP;\r\n'
2019-04-18 10:56:07 DEBUG (MainThread) [rflink.protocol] waiting for acknowledgement
2019-04-18 10:56:08 DEBUG (MainThread) [rflink.protocol] received data: 2
2019-04-18 10:56:08 DEBUG (MainThread) [rflink.protocol] received data: 0;79;OK;
2019-04-18 10:56:08 DEBUG (MainThread) [rflink.protocol] got packet: 20;79;OK;
2019-04-18 10:56:08 DEBUG (MainThread) [rflink.protocol] decoded packet: {'ok': True, 'protocol': 'unknown', 'node': 'gateway'}
2019-04-18 10:56:08 DEBUG (MainThread) [rflink.protocol] command response: {'ok': True, 'protocol': 'unknown', 'node': 'gateway'}
2019-04-18 10:56:08 DEBUG (MainThread) [rflink.protocol] packet acknowledged

Via remote control:

2019-04-18 13:51:39 DEBUG (MainThread) [rflink.protocol] received data: 20;8E;NewKaku
2019-04-18 13:51:39 DEBUG (MainThread) [rflink.protocol] received data: ;ID=00xxxxxx;SWITCH=d;CM
2019-04-18 13:51:39 DEBUG (MainThread) [rflink.protocol] received data: D=OFF;
2019-04-18 13:51:39 DEBUG (MainThread) [rflink.protocol] got packet: 20;8E;NewKaku;ID=00xxxxxx;SWITCH=d;CMD=OFF;
2019-04-18 13:51:39 DEBUG (MainThread) [rflink.protocol] decoded packet: {'id': '00xxxxxx', 'switch': 'd', 'protocol': 'newkaku', 'node': 'gateway', 'command': 'off'}
2019-04-18 13:51:39 DEBUG (MainThread) [rflink.protocol] got event: {'command': 'off', 'id': 'newkaku_00xxxxxx_d'}
2019-04-18 13:51:39 DEBUG (MainThread) [homeassistant.components.rflink] event of type command: {'command': 'off', 'id': 'newkaku_00xxxxxx_d'}
2019-04-18 13:51:39 DEBUG (MainThread) [homeassistant.components.rflink] entity_ids: ['cover.woonkamer_voor']
2019-04-18 13:51:39 DEBUG (MainThread) [homeassistant.components.rflink] passing event to cover.woonkamer_voor

The states are properly reported: Entity: cover.woonkamer_voor State: closed assumed_state: true supported_features: 11 friendly_name: Woonkamer (voor)

javicalle commented 5 years ago

@fmartens Thanks a lot for the traces and to test my code. I find quite strange that relation ON<->DOWN and OFF<->UP. I don't know how RFLink is implemented (the gateway, not the @aequitas library), but for me it seems like a RFLink bug with this cover, but I don't have other references to validate if this (on=down, off=up) is the default behavior with RFLink covers.

Anyway, about your question:

do you want me to submit the stuff and go through the administrative process or is that something you would like to do?

If you want, I have no problem if you make the PR. But I have to warn you that test will be needed, and this part can be painful (you will need to set up a development environment). I can give you some support, but I'm not an expert in Python either. But on the other hand, you can leave your name in the HA code, and this is very grateful ;-)

fmartens commented 5 years ago

I had to use inverted blinds in Domoticz to be able to work with these specific COCO/KAKU ASUN-650 devices and it feels strange. Here is a reference to the domoticz forum that shows that ON/DOWN and OFF/UP result in the same behavior.

I will do the PR for you, I want to learn a bit more about the home assistant environment. You've helped me out big time so this is the least I can do for you. The only name that should be in the new class is yours ;-)

javicalle commented 5 years ago

The only name that should be in the new class is yours ;-)

Do not worry, I do not have a special interest. I only think of more hands (and heads) helping.

I have a few more suggestions about the new class. Once you have your branch created I can PR you with suggestions.

Thank you for not giving up.

javicalle commented 5 years ago

I have done a few tests with my Somfy covers and, in my case, the results are the opposite:

OFF or UP => open
ON or DOWN => close

But the behavior in RFLink is consistent. I mean ON&DOWN commands get the same result (inverted from yours). The same with OFF&UP. So it would not be a bug.

I have made some research, and from what i have found, the remote of the KAKU covers came with ON / OFF buttons. If the installation is done so that the ON button raises the cover, there will always be an inverted behavior in HA.

javicalle commented 5 years ago

@WaaZaa666 (and others) for now it have a little work to remove the STOP button, but I think that it can be done with customization. It can be done from /config/customize section in HA.

Once there, you must edit the supported_features attribute and the value will be persisted in customize.yaml file. To calculate the value to set, you need to substrat 8 to the actual value (or what is the same X xor 8). If you have supported_features:15 put 7, if you have 11 --> 3

fmartens commented 5 years ago

@javicalle , thanks for the tip, I wasn't aware of that. It actually works. I hard-coded it to 3 because the ASUN-650 only supports open and close.

fmartens commented 5 years ago

@javicalle , I have a branch ready, InvertedRflinkCover.

javicalle commented 5 years ago

I have a branch ready, InvertedRflinkCover.

Checked. Later will make some suggestions.

Let's go for some testing. I recommend you create a new test at tests\components\rflink\test_cover.py with something like

async def test_inverted_cover(hass, monkeypatch):
    """Ensure states are restored on startup."""
    config = {
        'rflink': {
            'port': '/dev/ttyABC0',
        },
        DOMAIN: {
            'platform': 'rflink',
            'devices': {
                'test_inverted_1': {
                    'name': 'standard',
                    'type': 'standard',
                },
                'test_inverted_2': {
                    'name': 'inverted',
                    'type': 'inverted',
                },
            },
        },
    }

    # setup mocking rflink module
    event_callback, _, protocol, _ = await mock_rflink(
        hass, config, DOMAIN, monkeypatch)

    # test default state of cover loaded from config
    assert hass.states.get(DOMAIN + '.standard').state == STATE_CLOSED
    .../...

    # mock incoming up command event for all devices
    event_callback({
        'id': 'test_inverted_1',
        'command': 'up',
    })
    .../...
    await hass.async_block_till_done()

    assert hass.states.get(DOMAIN + '.standard').state == STATE_OPEN
    .../...

    # should respond to group command
    event_callback({
        'id': 'test_inverted_1',
        'command': 'alloff',
    })
    .../...
    await hass.async_block_till_done()

    assert hass.states.get(DOMAIN + '.standard').state == STATE_CLOSED
    .../...

    # the good one
    hass.async_create_task(hass.services.async_call(
        DOMAIN, SERVICE_OPEN_COVER, {ATTR_ENTITY_ID: DOMAIN + '.standard'}))
    .../...
    await hass.async_block_till_done()

    assert hass.states.get(DOMAIN + '.standard').state == STATE_OPEN
    assert protocol.send_command_ack.call_args_list[0][0][1] == 'UP'
    .../...

I let you fill in the dotted lines ;-P

fmartens commented 5 years ago

@javicalle , I'm under the impression that you are an experienced Python developer ;-)

javicalle commented 5 years ago

I like to think that I'm not a bad programmer, but you can believe that my knowledge of python is basic. I fought very hard with the tests, and I can copy&paste a lot of code. But if I had to start from scratch, I would not know how to begin. Lucky that there is a lot of good code to be inspired.

fmartens commented 5 years ago

The stuff that is there is good and an ideal platform to work from. You did a splendid job and I did not have to change that much on your code. Tests are passing at the moment, also the last one. I need to figure out if I need to add a few more test cases. I'll keep you posted.

fmartens commented 5 years ago

@javicalle, The code and unit tests are committed to my branch. The only thing left is the documentation. Is there anything else you would like to change/add?

javicalle commented 5 years ago

I have PR you one last thing. You do not have to take it into account if you do not feel comfortable. It is based on the assumption that all newkaku covers have the behavior of InvertedRflinkCover, and this can be a breaking change.

Otherwise I think you've done a good job. Thank you for your patience with my suggestions, I hope I have not been too intrusive.

fmartens commented 5 years ago

Give me a few moments to think about it. I like the idea.

fmartens commented 5 years ago

@WaaZaa666, @aequitas and @Emacee, @javicalle and I modified the current implementation of the RFLink cover. The new implementation will detect newkaku devices (ASUN-650) and flip the up/down command without configuration changes. Is this something you would like to have?

WaaZaa666 commented 5 years ago

@fmartens I just did a quick check, but all 4 of my ASUN's are indeed inverted. I was just wondering if someone might want to manually invert incase wiring was done incorrectly, but in my case I wont need this.

Perhaps to make it 'less breaking', detect the inverted devices, but allow for the inversion to be overruled from config? Just in case someone rewired the devices to cope with this issue? (I was going to rewire right untill I saw you guys working on this..)

fmartens commented 5 years ago

@WaaZaa666 , that is a fair point and it crossed my mind too. I think we account for this. Let me have a look and get back to you.

fmartens commented 5 years ago

It is hard to detect inverted devices but we are able to overrule the new behavior via the config file. I am currently working on additional unit tests that should test this 'feature'. Give me some time to finish the test cases and write some documentation about our changes. I hope I can make some time during the week. Big thanks goes to @javicalle, he showed me how I could do it better.

@WaaZaa666, as far as I know, KAKU only has the ASUN-650 for cover devices right?

WaaZaa666 commented 5 years ago

As far as I can find, only the ASUN-650 indeed.

stale[bot] commented 5 years ago

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates. Please make sure to update to the latest Home Assistant version and check if that solves the issue. Let us know if that works for you by adding a comment 👍 This issue now has been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.

fmartens commented 5 years ago

I will create a pull request as soon as possible. The local changes seem to work very well but I need to clean some unit tests

fmartens commented 5 years ago

Sorry for the delay, a lot of work and the summer break prevented me from working on the InvertedRflinkCover.

@WaaZaa666: The code first checks if the type property is specified and sets the behavior accordingly (standard or inverted). If the type property is not specified, then it only uses the inverted functionality when the ID starts with 'newkaku' and it uses the original functionality if the ID does not start with 'newkaku'. You can set the type property to 'standard' for newkaku devices to keep the old behavior.

Configuration examples:

A KAKU device that does not invert the commands (type is specified and set to 'standard'): 'newkaku_dev_1' : { 'name': 'my_cover1', 'type': 'standard' },
A KAKU device that inverts the commands (type is specified and set to 'inverted'): 'newkaku_dev_2' : { 'name': 'my_cover2', 'type': 'inverted' },
A KAKU device that inverts the commands (type is omitted and the ID starts with 'newkaku'): 'newkaku_dev_3' : { 'name': 'my_cover3' },
An non-KAKU device that inverts the commands (type is specified and set to 'inverted'): 'nonkaku_dev_4' : { 'name': 'my_cover4', 'type': 'inverted' },
An non-KAKU device that does not invert the commands (type is specified and set to 'standard'): 'unnamed_dev_5' : { 'name': 'my_cover5', 'type': 'standard' },
A non-KAKU device that does not invert the commands (type is omitted and the ID does not start with 'newkaku'): 'unnamed_dev_6' : { 'name': 'my_cover6' }, Is this something you can live with?

@javicalle: I've updated the test class a little, all configuration options are covered. All unit tests do pass and the code is available in github.

I am about to do a pull request, but I first need to update the documentation, I will work on that during this week. Is there anything else that comes to your mind before releasing the functionality to the community?

fmartens commented 5 years ago

@WaaZaa666 : Are you willing to test the changes? I am running the code since April and I have not seen it misbehaving.

javicalle commented 5 years ago

Nowadays I'm on holidays and I can't take a deep review, but I think that you have make a very good job with the test cases.

I'm not sure, but I think that your code is too away from master. I have made a mess in the past trying to rebase my code. I suggest to made a backup from your code before trying. If things get ugly, you can make another branch from master and put your code there.

Also be aware that CI have changed (code style) and some rules can be different.

Thanks for all the job you have done.

fmartens commented 5 years ago

I noticed, i wil give it a shot.

fmartens commented 5 years ago

@javicalle : It seems that the merge worked out, I am awaiting the CI results

fmartens commented 5 years ago

@javicalle and @WaaZaa666 , thank you for your valuable input and help resolving this issue. I have the changes running since May and now I can update without reworking the cover.py file. @MartinHjelmare , thank you for spending the time to review the pull request, I appreciate it.

javicalle commented 5 years ago

Sorry for my late response. You have done a great work with the code and the documentation. I belive it will be very helpful for Newkaku owners and for future covers integrations. Thanks to you for not giving up :wink: .

jaccobezemer commented 1 year ago

Hello, I'm reading that is problem should have been solved. I just added the RFLink integration in order to operate my KAKU ASUN-650 and experience that the stop button is not functioning. Up and down buttons are working ok. This is my configuration:

cover:
  - platform: rflink
    devices:
      newkaku_0074a266_b:
        name: "rolluik deur"      
        type: standard
      newkaku_0074a266_c:
        name: "rolluik raam"      
        type: standard

Is something wrong with my configuration?

These are my version's: Home Assistant 2023.7.1 Supervisor 2023.07.1 Operating System 10.3 Frontend 20230705.1 - latest

fmartens commented 1 year ago

The ASUN 650 does not implement the stop command, you need to repeat the last command. I only fixed the inverted commands.

Op di 11 jul. 2023 22:22 schreef jaccobezemer @.***>:

Hello, I'm reading that is problem should have been solved. I just added the RFLink integration in order to operate my KAKU ASUN-650 and experience that the stop button is not functioning. Up and down buttons are working ok. This is my configuration:

cover:

platform: rflink devices: newkaku_0074a266_b: name: "rolluik deur" type: standard newkaku_0074a266_c: name: "rolluik raam" type: standard

Is something wrong with my configuration?

These are my version's: Home Assistant 2023.7.1 Supervisor 2023.07.1 Operating System 10.3 Frontend 20230705.1 - latest

— Reply to this email directly, view it on GitHub https://github.com/home-assistant/core/issues/10810#issuecomment-1631460028, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEFRROKMYNQLTZFPQLOPKR3XPWYYHANCNFSM4EFLH7TQ . You are receiving this because you were mentioned.Message ID: @.***>

jaccobezemer commented 1 year ago

I know, but I thought that this was overcome in the software. Apparently i did not read properly 😞

home-assistant / core

RFLink-cover 'stop' not working and inverted up/down with KAKU devices #10810