Set TX-Delay to 60 seconds when gateway is found by initialization

[tp1de]

I recorgnized that some users do not read documentation and therefore do not set tx-delay in ems-esp setting while having a km200 gateway.

This could bring up quite some problems.
I recommend to set tx-delay to 60 seconds automatically, when a gateway is found during start-up and tx-delay is still set to initial 0 (.. or any value below 30 seconds). Maybe a warning should be seen on the WEB-UI setting screen.

This could avoid complications for users not familiar with such requirements.

@proddy What do you think?

[proddy]

makes sense. I'll discuss with Michael.

[tp1de]

.... or the easiest way is to set tx delay to 60 seconds for all. One minute waiting doesn't hurt as well.

[proddy]

the majority of the users don't have a KM200 and when EMS-ESP powers up they would expect data to flow in immediately as it does now.

[proddy]

@MichaelDvP one alternative is to always send out the UBADevices request after the 1st poll, wait for the response and if a KM200 is detected set the tx_delay automatically to 60 seconds, otherwise open up Tx. This way we can remove the tx_delay setting.

[MichaelDvP]

If writing to the bus within the first 60 sec crashes the KM200, a write of UBADevices should also crash the KM200. Waiting for a broadcast of UBADevices can take up to 60 sec. I don't know what the KM200 do the first seconds, if it starts sending we can delay tx for 3 secondes and another 57 if we receive messages from 0x48 (i think this is fixed for KM200). Someone with KM should give us a syslog trace from the the first minute.

[tp1de]

I just recommend to make it easy to protect new users who do not read any documentation.

Either set tx-delay by standard (initial value) to 30 secs or higher or do it within startup of ems-esp:
When tx delay is set to 0 (initial value) and km200 gateway is found set it automatically to 60 secs.
Manually this can then be reduced, but at least this takes a manual intervention and hopefully some thinking.

The problem of crashing the ems-bus (not the km200) is related to the ems-bus scan to identify active devices when the heating system is repowered (e.g. after maintenance switch off). Then the bus scan of the master controller doesn't find all devices or put some in error state (in my case the mm100). I do not know why this problem is related to km200 only. It might be a timing problem when ems-esp and km200 are requesting in parallel data from the ems-bus for their initialization.
But since this bus scan takes in my case approx 15-20 seconds, a 30 seconds delay is enough and 60 seconds to be on a save side.

[MichaelDvP]

I just recommend to make it easy to protect new users who do not read any documentation.

In #92 you can see that users complain if not all telegrams and devices are registered after uptime of 4 sec. An unexpected delay is more confusing to new users.

I do not know why this problem is related to km200 only.

But without knowing the real cause it is difficult to find a solution.
Can you please make a log all (in syslog) from start with km200 and emsesp with 60 sec tx-delay. Than we can see the master-scan and km200 interaction.

[proddy]

I agree. When people start EMS-ESP that want it to work instantly. We should find out the root cause of the UBADevices scan messing up the KM200. There is probably some handshaking going on between the Master and devices when they boot up. If we can capture those and decypher what is happening.

[tp1de]

I recommend to put this detailled analysis on lower priority and do it later.

I just recognized that people buy the gateway from BBQKees and then wonder that my ioBroker Adapter does'nt work because the firmware update was not done. (They haven't read the readme).Same with km200. Most people use service jack connection and powering. Tx delay was not set. (3 users up to yet). I reminded them that this is important.

To make it easy I recommended to have a general tx-delay.
BTW: My other homeautomation services (ccu3 for homematic / ioBroker / km200 / raspi's) need longer then 30 seconds to start !

What about having a warning message on setup-screen when tx-delay is 0 and km200 gateway found.

[proddy]

we usually send a read request to the Master UBA to see which devices are on the EMS line. That way we know about the km200 gateway and I think its also that command that causes all the issues and puts your other modules into a dead state?

[tp1de]

Yes most probably if you send the read request before Master UBA knows all devices because scanning of EMS-bus by Master UBA is not finalized yet. Scanning is done whenever Boiler is switched on.

Some device have a fixed address other like the MM100 mixer have a selectable address. These have to be scanned.
And it's the MM100 which goes into error state (blinking led) and as a result the heating circuits info is corrupted.

[MichaelDvP]

@tp1de I think you should read how the bus works.

I've made a log from starting the system (by mains switch) with emsesp powered by service-jack. All works good.
ems-startup-log.txt

• After powerup the boiler requests version from controller.
• Than the controller queries and sets some boiler parameters (i don't know what telegram 0x04 is).
• Emsesp is first polled after 19 sec and sends out the UBADevices telegram(150), the master only have registered controller, boiler and emsesp at this time (152).
• The other devices are polled later in order of there id sending some telegrams and than broadcasting there version information. First thermostat after 27 sec (309), than mixer after 29 sec (347) and last solar after 45 sec (511).
• The boiler is broadcasting the found devices in UBADevices-Message at 32 sec (389) with additional thermostat and mixer, and at 47 sec (532) with also solar. After this the 0x07-message is broadcasted every minute. I wonder why emsesp requests again in 2079, after 5:28 minutes.

Looks all good to me, the km200 should be polled at las,t because of it's high device-id (0x48). Maybe km200 does not register because it sees another control-device (moden/servicekey, etc) I don't see any other reason. I'm waiting for a complete log with km200 now and will not participate on this diskussion any more until it is posted.

[tp1de]

I'm waiting for a complete log with km200 now and will not participate on this diskussion any more until it is posted.

Since this is not my personal problem I will put it on low priority as well.
The tx delay gives a stable startup procedure. That's enough for me.