alengwenus / pypck

Asynchronous LCN-PCK library written in Python
MIT License
8 stars 4 forks source link

dyn text leads to dimmable leds to spike #113

Open krismarc opened 2 months ago

krismarc commented 2 months ago

Hi there,

I'm using dyn.text service to display outside temperature taken from external service on lcn panels. Whenever 5 parts of the dyn text are reaching the bus then dimmable gu10 bulbs are spiking (those which are connected to UPP together with lcd panel). Any ideas how to prevent this?

Best regards, K.M.

krismarc commented 2 months ago

I just took a brief look at the code. https://github.com/alengwenus/pypck/blob/e0264103d46a49ed1a13117403c0187928252aba/pypck/module.py#L604 any reason for not breaking the loop here if part is empty?

text = " "
encoded_text = text.encode("utf-8")
parts = [encoded_text[12 * part : 12 * part + 12] for part in range(5)]
for part_id, part in enumerate(parts):
    print(part_id, part)
0 b' '
1 b''
2 b''
3 b''
4 b''
for part_id, part in enumerate(parts):
    if part:
        print(part_id, part)
    else:
        break
0 b' '
alengwenus commented 2 months ago

All parts of the displayed message can be addressed individually. If not all parts are sent, former messages get not cleared correctly from the display.

krismarc commented 2 months ago

Thx for quick reply. I've played around with your code locally (outside HA).

and seems like I have found a workaround for my problem. If there's no confirmation from the bus then light doesn't blink..

if I switch is_group to False then it doesn't blink and there's no green confirmation in LCN PRO on the bus. Directly here: https://github.com/alengwenus/pypck/blob/e0264103d46a49ed1a13117403c0187928252aba/pypck/module.py#L606 ..or by calling dyn_text_part separately using send_command myself.

I don't really need confirmation for sending part of something to be displayed on the panel.

Is my understanding correct that it's similar to UDP/TCP?

import asyncio

from pypck.connection import PchkConnectionManager
from pypck.lcn_addr import LcnAddr
from pypck.pck_commands import PckGenerator

async def main():
    async with PchkConnectionManager(
        "**",
        4114,
        username="lcn",
        password="**",
        settings={"SK_NUM_TRIES": 0},
    ) as pck_client:
        module = pck_client.get_address_conn(LcnAddr(0, 32, False))

        text = "123456789012345678901234567890"
        await module.dyn_text(1, text)

        await module.send_command(
                False,
                PckGenerator.dyn_text_part(1, 0, text.encode("utf-8")),
            )

        #await asyncio.sleep(3)
        #await module.dim_output(2, 0, 0)

asyncio.run(main())
krismarc commented 2 months ago

I'm not installer and I'm just working on existing installation in my place. By reading your comments in https://github.com/alengwenus/pypck/blob/dev/pypck/lcn_addr.py makes me thing it's something with my setup which causes your project to consider it multisegment or so? So at the end this makes 'is_group' to be True and forces acknowledges to be requested.

While operating with LCN outside HA, there are no acknowledges send for any operations (I see this on the bus). Only operations made by your project sends acks for any operation. Maybe it would be nice to have an option to disable acks in general or for specific commands?

Without acknolwedges, your HA integration performs a way faster for me and causes no issue like bulbs spikes or so.

krismarc commented 3 weeks ago

Hi @alengwenus,

did you had any chance to consider this? In HAOS I can't simply override existing/official integration. The workaround is changing the code within docker images which are recovered to official version with each HAOS upgrade.

So question, can we have an option to disable acknowledges via configuration.yaml? :)

Best regards, K.M.

alengwenus commented 3 weeks ago

Hi @krismarc , implementing a configuration.yaml option to switch the achknowledge commands on/off would be quite easy. Unfortunately there has been an architectural decision by the HA core developers to not accept new configuration options for integrations which still rely on a configuration.yaml. This has been decided in favour of UI configurations using config entries (that means the configuration is stored in the internal HA database). In a nutshell this means, that the LCN integration has to be adapted, so it can be configured using the UI solely. I'm working on this for quite some time but as LCN has not the highest priority of all integrations, the review process is lengthy. However, you can monitor the progress here.

As soon as the mentioned PR is merged, I would have the possibility to add an additional configuration option to switch the acknowledgement commands on/off.

krismarc commented 3 weeks ago

@alengwenus thanks for sharing all those details. You're doing great job. Highly appreciated. The panel looks promising. Is it just a sort of frontend for existing LCN configuration and the panel will became available out of actual configuration? or is it something to be configured over again?

Regarding my request. No worries then. It's not super urgent, I'm rather looking for long term solution. I'm happy to hear you're willing to support such feature 👍

I'm looking further to become your tester 😄

alengwenus commented 3 weeks ago

Once the panel got merged, the configuration from the configuration.yaml is imported and stored in the HA database on startup. You will then get a notification that you can safely delete the LCN configuration from the configuration.yaml. The imported configuration can then be viewed/modified from the new UI panel. Besides the import functionality you can of course start from scratch and set up a new configuration solely from the UI.

Unfortunately the PCK protocol does not allow to read-out the configs from the LCN modules. If that would be the case, I guess there would not be the need for the new panel because everything could be discovered on the fly. But well, that's the way it is with such a "closed" system like LCN.