-
-
Notifications
You must be signed in to change notification settings - Fork 108
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Refactor Telegram.payload
to support other APCI payloads
#519
Conversation
I have two MyPy errors left, which I don't understand:
False positive? |
Have you seen this: python/mypy#7423 |
when I run this now from my HA test installation I get a lot of 2020-12-01 22:12:26 WARNING (MainThread) [xknx.log] 'from_knx()' not implemented for GroupValueRead
# and this for GAs in fire_event_filter
2020-12-01 22:12:26 WARNING (Recorder) [homeassistant.components.recorder] Event is not JSON serializable: <Event knx_event[L]: data=<GroupValueResponse dpt="<DPTArray value="[0x19,0x62]" />" />, destination=5/1/0, direction=Incoming, source=1.0.54, telegramtype=GroupValueResponse> also I think it would be cleaner if the APCI services could get their own module for importing them instead of importing from xknx.telegram together with higher-order classes # eg
from xknx.telegram import GroupAddress, IndividualAddress, Telegram
from xknx.telegram.apci import GroupValueRead, GroupValueWrite
# instead of
from xknx.telegram import GroupAddress, GroupValueRead, GroupValueWrite, IndividualAddress, Telegram |
@farmio Thanks for testing, I'll pick it up. I'm also busy with a few other improvements. |
I'm still working on the APCI unit tests. |
Unit tests are ready. Let's see what I have to add more :-) |
6445ed1
to
b3196da
Compare
0e2c435
to
899b441
Compare
This becomes unnecessary if the telegram type can be derrived from the payload.
Thi adds payload classes that represent APCI messages, such as GroupValueRead/Write/Response.
This adapts all Telegram payload objects to the corresponding APCI payload objects. It removes the need for `Telegram.telegramtype`.
This can be derived from the payload of the telegram.
Byte 8 (mpdu_len) is the length of the APDU minus one. This can be calculated from payload.calculated_length().
Unless a developer uses the TelegramQueue or Device class directly, there doesn't seem to be a need for this check.
This removes the need for a constructor and false implementations of the abstract methods.
Typing was necessary here for APCI code to be type checked.
899b441
to
df2fccd
Compare
Thanks! |
Thank you! I think its a great addition. 🙏 |
Description
This is the second part of #253, where
Telegram.payload
is refactored to support generic APCI payloads. In addition,Telegram.telegramtype
andCEMIFrame.cmd
are obsolete as well, because they can be derived from the payload.Most of the changes are related to the testcases, where
Telegram(.., payload=DPT*())
is now (for example)Telegram(.., payload=GroupValueWrite(DPT*()))
.I have not tested the Home-Assistant plugin, as I don't have a setup running. It probably needs some changes.
Type of change
Checklist: