search

thelsing / knx

knx stack (TP, IP and RF) for arduino and linux, Can be configured with ETS
GNU General Public License v3.0
257 stars 91 forks source link

Debug message since commit 338aa1b of 2023-05-28 maybe inconsistent ? #247

Closed Maggyver closed 1 year ago

Maggyver commented 1 year ago

Debug message before commit 338aa1b from 2023-05-28:

. restored Tableobjects Timeout: 0 Zykl. senden: 0 Min/Max senden: 0 Aenderung senden: 0 Abgleich: 0 ownaddr 1114 Start

Debug message since commit 338aa1b from 2023-05-28:

. restored Tableobjects Timeout: 0 Zykl. senden: 0 Min/Max senden: 0 Aenderung senden: 0 Abgleich: 0 ERROR, TPUART not responding Start

Tested with two TP-UART ́s and three NANO-BCU (NCN5120).

However, sample program works without any problems.

Bus reset, programming of the physical address and the group address without any problem.

The KNX devices work without restriction.

Ing-Dom commented 1 year ago

yes this is true, i can confirm that. The log is misleading.

should be reworked. any ideas @thewhobox ?

thewhobox commented 1 year ago

I can confirm that this happens to me as well.

I will have a look at it if i have some time^^

thewhobox commented 1 year ago

https://github.com/OpenKNX/knx/tree/fix-tpuart-error I think i fixed it. It now blocks the core when DataLinkLayer gets enabled and tpuart is not _enabled. I think this is a good compromis, since this will happen only at startup with max 100ms block time.

Would be great if someone can confirm its working.

Maggyver commented 1 year ago

I tested it. The output behaves as expected.

Can anyone else confirm this?

Ing-Dom commented 1 year ago

works for me

thewhobox commented 1 year ago

Other question: Shouldnt be the error message be printed also when the tpuart doesnt respond in a later event? So if you start now and it works no error is shown, if you now disconnect the bcu there will be no error message.

Should we change that behavior?

Maggyver commented 1 year ago

The basic diagnostics should include monitoring the two hardware pins, SAVEB and RESETB.

A kind of active monitoring could be realized via the state service request ... this allows you to detect the "failure" of TP-UART and that of the NCN51xx.

If desired.

thewhobox commented 1 year ago

I think this is too far for now. I will create a pull request which will fix this issue. Afterwards we can implement more.