Skip to content
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

IP router #160

Open
Avenitos opened this issue Dec 24, 2021 · 11 comments
Open

IP router #160

Avenitos opened this issue Dec 24, 2021 · 11 comments

Comments

@Avenitos
Copy link

Hello!

is it possible to make a router between TP and IP?
are there any examples?

@thelsing
Copy link
Owner

thelsing commented Dec 25, 2021

See the *coupler examples. I didn't try them. @nanosonde is the routing expert here.

@Avenitos
Copy link
Author

there's almost no code there :)

It is necessary to call the callback when passing telegrams and filter them when passing to another interface

@nanosonde
Copy link
Contributor

there's almost no code there :)

It is necessary to call the callback when passing telegrams and filter them when passing to another interface

It is correct that the code examples do not contain any code related to routing.

The code related to routing is included in the stack itself.
I have implemented the routing as described in the KNX spec.
However, to really use it, you would have to create your ETS product database for a coupler. It could be done, but I did not have any further time to work on this.
As soon as you would add this product database to ETS, the idea is to use this coupler like an other coupler. ETS will handle writing the filter tables, etc. This should be part of this stack already.

@nanosonde
Copy link
Contributor

Concerning the coupler product database, I would recommend to look at a database of an already existing coupler. Should not be to hard to create our own one and use the CreateKNXProd tool.

@Avenitos
Copy link
Author

It's good that the stack can do everything by itself! But with non-standard tasks, it can be difficult.

In my task, it is necessary to make a decision on filtering the telegram from my project, as well as to create a cache for group addresses, the application, which will be accessed from IP KNX, generates a large number of group address value reads at the time of launch, and there is no way to do without a cache.

For this purpose, it is necessary to be able to integrate into the telegram routing process.

project based on ESP 32 + TPUART2 + Ethernet

@thelsing
Copy link
Owner

I think it would be best if you get the default coupler working first. After that you can add caching. You could also add a callback that can be registered for filtering. Or add some properties that influence forwarding to the knxprod like "only forward if value changed". More examples (even more complex ones) are always welcome as pull requests.

@Avenitos
Copy link
Author

Avenitos commented Dec 26, 2021

OK, let's start with a simple one. I connected tpuart, how do I logging all the telegrams in the log? Thanks!

@nanosonde
Copy link
Contributor

OK, let's start with a simple one. I connected tpuart, how do I logging all the telegrams in the log? Thanks!

For group addresses look here:

bool NetworkLayerCoupler::isGroupAddressInFilterTable(uint16_t groupAddress)

@Avenitos
Copy link
Author

Oh… Do I need to edit the sdk to output telegrams to the log?

@nanosonde
Copy link
Contributor

Just for the records. I have added some more (german) comments here: https://knx-user-forum.de/forum/projektforen/openknx/1780408-fragen-zum-routing-im-knx-stack?p=1780447#post1780447

@mgoeller
Copy link

mgoeller commented Feb 6, 2023

Oh… Do I need to edit the sdk to output telegrams to the log?

@Avenitos did you proceed any further on this? If yes I would appreciate an email to "mailgoe at gmail.com" and have an offer for you.
Thank you!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants