search

arendst / Tasmota

Alternative firmware for ESP8266 and ESP32 based devices with easy configuration using webUI, OTA updates, automation using timers or rules, expandability and entirely local control over MQTT, HTTP, Serial or KNX. Full documentation at
https://tasmota.github.io/docs
GNU General Public License v3.0
21.97k stars 4.77k forks source link

KNX Read reply for Power not working #9236

Closed martiko70 closed 3 years ago

martiko70 commented 4 years ago

PROBLEM DESCRIPTION

My Tasmota Device does not reply to Read Requests for Power. Based on other Issued and examples, to my mind, the KNX settings are configured correctly, so:

Data to Send to Group Addresses: Output 1 -> 1 / 2 / 80 Power -> 1 / 3 / 80

Group Addresses to Receive Data from: 1 / 1 / 80 -> Output 1 (remark: for setting the value to on / off) 1 / 2 / 80 -> Output 1 (remark: for read requests of the current state of Output 1) 1 / 3 / 80 -> Reply Power

The KNX communication in general is working fine and for Output 1, I can set and read the State from KNX, but for Power, the KNX Read (on GA 1/3/80) is not answered.

Additional Information: The periodical send of Power to KNX is working fine, so the value is measured correctly and at least the sending to KNX is working fine, respective Console output looks like this: `05:53:08 KNX: Power sent to 1.3.80

REQUESTED INFORMATION

Make sure your have performed every step and checked the applicable boxes before submitting your issue. Thank you!

TO REPRODUCE

See description

EXPECTED BEHAVIOUR

KNX read should be answered the same way as for Output 1

SCREENSHOTS

If requiried, I can add Screenshots, but I think I have explained everything in my text...

ADDITIONAL CONTEXT

N/A

(Please, remember to close the issue when the problem has been addressed)

ascillato commented 4 years ago

Hi,

Thanks for reporting. Your settings are ok but what is happening is that Tasmota will answer a KNX read request only for relays, temperature and humidity. It is not implemented for POWER. I will add it. Tagging this issue as a Enhancement.

Until it is implemented, if you want, you can use a rule to answer that read request.

Just a reminder from #3165 for anyone reaching this issue (I have to add this also to the docs)

Tasmota answer the state when a read request arrives to the "group address to receive data".

Tasmota is not listening the "group address to send data"

martiko70 commented 4 years ago

@ascillato Thanks, sounds good! I will have a look at the updates and test of it’s working.

martiko70 commented 4 years ago

PS: I tried to solve the issue with a rule as an interim solution, but I did not succeed...

I added the KNX GA assignements for send and receive (1/3/80) for KNX TX 1 and KNX RX 1 and used this rule: rule on event#knxrx_req1 do knxtx_val1 %ENERGY_POWER% endon

There was no response sent do KNX, no matter what I used as variable between the % (ENERGY, POWER...). What am I doing wrong here?

ascillato commented 4 years ago

The problem is that %ENERGY_POWER% is not a valid variable in Tasmota. Where did you take it from? It isn't in Tasmota docs.

At this moment, the only way is to make a rule to store it in a VAR (like the example in the rule's cookbook that sends a value of a sensor using a threshold) and replying the value of that VAR using %var1% for example.

Anyway, as soon as I have some free time, I'll add this feature request.

pfisterer commented 3 years ago

@ascillato I'm not sure if this is related. I've installed a number of Gosund SP112 devices with KNX/IP support. Together with the IP <--> TP gateway based on knxd, I'm able to interact with any other twisted-pair-based KNX device. Thanks for the hard work!

However, the Tasmota-based devices always show up as OFFLINE in Openhab:

image image image

Any ideas?

ascillato commented 3 years ago

Any ideas?

Sorry, no idea. I don't use OpenHab. Seems that you need to do an extra config in OpenHab. In KNX there is no ONLINE-OFFLINE status. Your Tasmota config is correct.

pfisterer commented 3 years ago

@ascillato Thank you for looking into this. As it uses plain KNX packets, I guess this is not specific to OpenHab. However, I tried to find out how OpenHab performs this check.

The sequence of function calls is as follows:

which finally invokes

Destination dst = mc.createDestination(devAddr, true)
mc.readDeviceDesc(dst, 0);

The implementation of public byte[] readDeviceDesc(final Destination dst, final int descType) is as follows: 

@Override
public byte[] readDeviceDesc(final Destination dst, final int descType)
    throws KNXInvalidResponseException, KNXDisconnectException, KNXTimeoutException,
    KNXLinkClosedException, InterruptedException
{
    if (descType < 0 || descType > 63)
        throw new KNXIllegalArgumentException("descriptor type out of range [0..63]");
    final byte[] apdu = sendWait2(dst, priority, DataUnitBuilder.createLengthOptimizedAPDU(
            DEVICE_DESC_READ, new byte[] { (byte) descType }), DEVICE_DESC_RESPONSE, 2, 14);
    final byte[] dd = new byte[apdu.length - 2];
    for (int i = 0; i < apdu.length - 2; ++i)
        dd[i] = apdu[2 + i];
    return dd;
}

Does this help you somehow?

Here is the code for sendWait2:

private byte[] sendWait2(final Destination d, final Priority p,
    final byte[] apdu, final int response, final int minAsduLen, final int maxAsduLen)
    throws KNXDisconnectException, KNXTimeoutException, KNXInvalidResponseException,
    KNXLinkClosedException, InterruptedException
{
    final long start = send(d, p, apdu, response);
    return waitForResponse(d.getAddress(), response, minAsduLen, maxAsduLen, start, responseTimeout);
}
ascillato commented 3 years ago

Sorry but as I don't use OpenHab, I don't know how to help you on that. In HomeAssistant I just enable KNX and config it as HomeAssistant's docs and it works without any special setting. KNX devices are never shown as offline or online. From Tasmota side, the implementation of KNX is the KNX-IP that is a Multicast communication. In that KNX standard, there isn't any online or offline device. It just sends the commands. There is another standard that is KNX-IP tunneling. That one is not implemented in Tasmota and uses a different approach for communicating devices. If that is what expects OpenHab, it is not going to work. You need to config OpenHab for KNX-IP Multicast.

ascillato2 commented 3 years ago

Fixed in proposed PR #9891

Sorry for the delay.

Please test. Thanks.

martiko70 commented 3 years ago

@ascillato2 Sorry, I am not so familiar with github etc... How can I install the patch for testing and which version has to be installed on the plug?

PS: On one plug I already installed the latest 9.1.0

ascillato commented 3 years ago

Just install the latest Tasmota version 9.1.0.2

http://ota.tasmota.com/tasmota/tasmota-knx.bin

martiko70 commented 3 years ago

@ascillato2 Thanks for the quick reply! I Installed it OTA with this link (which I used also before), but on my Info-Screen it still shows that I use version 9.1.0:

Program Version | 9.1.0(knx) Build Date & Time | 2020-11-07T11:59:00 Core/SDK Version | 2_7_4_5/2.2.2-dev(38a443e)

ascillato commented 3 years ago

Please, copy and paste the link.

Your version is taken from release:

http://ota.tasmota.com/tasmota/release/tasmota-knx.bin

And you need latest development version that is:

http://ota.tasmota.com/tasmota/tasmota-knx.bin

martiko70 commented 3 years ago

@ascillato Thanks, as mention for 9.1.0.2 it unfortunately does not work (for me). The Read-Request is received, but (still) not answered.

Just to be sure, I am talking about the "Power", have you probably implemented the automated response for a differerent sensor-value (e.g. Current, Voltage...)?

My Configuration is still: Data to Send to Group Addresses: Output 1 -> 1 / 2 / 80 Power -> 1 / 3 / 80

Group Addresses to Receive Data from: 1 / 1 / 80 -> Output 1 (remark: for setting the value to on / off) 1 / 2 / 80 -> Output 1 (remark: for read requests of the current state of Output 1) 1 / 3 / 80 -> Reply Power

Power is sent correctly after the configured interval, so the configuration as such is working fine....

ascillato commented 3 years ago

Please, set weblog to 4 and share the ouput of the console when your knx network asks for the power value. Thanks

martiko70 commented 3 years ago

Good morning, I set weblog to 4 but there where no additional outputs (direcly related to the read request). Just later (and repeated) checke connection:#

`07:10:11 KNX: Received from 1.3.80 Command Read: 0 to Reply Power

07:10:24 WIF: Checking connection...

07:10:44 WIF: Checking connection...

07:11:04 WIF: Checking connection...

07:11:24 WIF: Checking connection...

07:11:44 WIF: Checking connection...

07:12:04 RSL: STATE = {"Time":"2020-11-23T07:12:04","Uptime":"5T11:08:12","UptimeSec":472092,"Heap":22,"SleepMode":"Dynamic","Sleep":50,"LoadAvg":20,"MqttCount":0,"POWER":"ON","Wifi":{"AP":1,"SSId":"koe","BSSId":"E0:28:6D:73:D6:AF","Channel":6,"RSSI":100,"Signal":-48,"LinkCount":15,"Downtime":"0T00:00:33"}}

07:12:04 KNX: Power sent to 1.3.80

07:12:04 RSL: SENSOR = {"Time":"2020-11-23T07:12:04","ENERGY":{"TotalStartTime":"2020-08-01T13:37:20","Total":0.110,"Yesterday":0.024,"Today":0.004,"Period":2,"Power":61,"ApparentPower":65,"ReactivePower":22,"Factor":0.94,"Voltage":231,"Current":0.280}}

07:12:04 WIF: Checking connection...`

ascillato commented 3 years ago

ok, thanks for the logs. Let me do some more tests.

martiko70 commented 3 years ago

@ascillato Thanks! Just keep me informed as soon as you release a new version for testing...

ascillato2 commented 3 years ago

Tested and works as expected.

Please, check that you are using the following DPTypes:

14.030  electromotive_force 4bytes float        V
14.056  power           4bytes float        W
martiko70 commented 3 years ago

@ascillato2 Thanks for your repsonse. Unfortunately, I cannot confirm that it is working, although I have configured it (to my mind) correctly... First of all, just to be sure, this is my KNX-Configuration for the plug:

Bildschirmfoto von Firefox (28-11-20, 07-09-03)

And in KNX, I have defined GA as 14.056 (I have only configured power, I do not need the value for voltage), and this power value as such is transferred correctly to KNX which I can prove for the periodical sends (I see it in the KNX logs and in my visualization).

But what is still not working realiably (for me) is, that I sent a read request from KNX (for power) to the plug and the plug directly responds with the latest sensor value. In my first tests, I thought that it would just not respond at all. But based on your response that it is working for you. I did additional tests and found out, that it sometimes responds, but must of the time, it does not... So if I send a couple of read requests, I get a response after a couple of tries... I see in the Plug-Console that all Read-Requests are received, but only very few are answered. This is completely different to the on/off state, there, really every read-request is answered immediately (that's why I am quite sure that it's not a network or configuration problem). Here are the KNX-Logs where this is really obvious, probably you can have a look at it and check this strange behaviour:

| Zeit | Dienst | Flags | Prio | Quelladresse | Quellname | Zieladresse | Zielname | Rout | Typ | DPT | Info

-- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- 88 | 28.11.2020 07:24:11,718 | zum Bus |   | Niedrig | 1.1.13 |   | 1/2/80 | Portabel - Plug-01 - Status Schalten | 6 | GroupValueRead |   |   89 | 28.11.2020 07:24:11,788 | vom Bus |   | Niedrig | 1.0.80 | Plug-01-IP | 1/2/80 | Portabel - Plug-01 - Status Schalten | 5 | GroupValueResponse | 1.011 Status | $00 | Inaktiv 90 | 28.11.2020 07:24:12,460 | zum Bus |   | Niedrig | 1.1.13 |   | 1/2/80 | Portabel - Plug-01 - Status Schalten | 6 | GroupValueRead |   |   91 | 28.11.2020 07:24:12,511 | vom Bus |   | Niedrig | 1.0.80 | Plug-01-IP | 1/2/80 | Portabel - Plug-01 - Status Schalten | 5 | GroupValueResponse | 1.011 Status | $00 | Inaktiv 92 | 28.11.2020 07:24:13,170 | zum Bus |   | Niedrig | 1.1.13 |   | 1/2/80 | Portabel - Plug-01 - Status Schalten | 6 | GroupValueRead |   |   93 | 28.11.2020 07:24:13,246 | vom Bus |   | Niedrig | 1.0.80 | Plug-01-IP | 1/2/80 | Portabel - Plug-01 - Status Schalten | 5 | GroupValueResponse | 1.011 Status | $00 | Inaktiv 94 | 28.11.2020 07:24:13,777 | zum Bus |   | Niedrig | 1.1.13 |   | 1/2/80 | Portabel - Plug-01 - Status Schalten | 6 | GroupValueRead |   |   95 | 28.11.2020 07:24:13,812 | vom Bus |   | Niedrig | 1.0.80 | Plug-01-IP | 1/2/80 | Portabel - Plug-01 - Status Schalten | 5 | GroupValueResponse | 1.011 Status | $00 | Inaktiv 96 | 28.11.2020 07:24:14,376 | zum Bus |   | Niedrig | 1.1.13 |   | 1/2/80 | Portabel - Plug-01 - Status Schalten | 6 | GroupValueRead |   |   97 | 28.11.2020 07:24:14,429 | vom Bus |   | Niedrig | 1.0.80 | Plug-01-IP | 1/2/80 | Portabel - Plug-01 - Status Schalten | 5 | GroupValueResponse | 1.011 Status | $00 | Inaktiv 98 | 28.11.2020 07:24:19,121 | zum Bus |   | Niedrig | 1.1.13 |   | 1/3/80 | Portabel - Plug-01 - Stromverbrauch | 6 | GroupValueRead |   |   99 | 28.11.2020 07:24:20,133 | zum Bus |   | Niedrig | 1.1.13 |   | 1/3/80 | Portabel - Plug-01 - Stromverbrauch | 6 | GroupValueRead |   |   100 | 28.11.2020 07:24:20,684 | zum Bus |   | Niedrig | 1.1.13 |   | 1/3/80 | Portabel - Plug-01 - Stromverbrauch | 6 | GroupValueRead |   |   101 | 28.11.2020 07:24:21,167 | zum Bus |   | Niedrig | 1.1.13 |   | 1/3/80 | Portabel - Plug-01 - Stromverbrauch | 6 | GroupValueRead |   |   102 | 28.11.2020 07:24:21,594 | zum Bus |   | Niedrig | 1.1.13 |   | 1/3/80 | Portabel - Plug-01 - Stromverbrauch | 6 | GroupValueRead |   |   103 | 28.11.2020 07:24:21,847 | zum Bus |   | Niedrig | 1.1.13 |   | 1/3/80 | Portabel - Plug-01 - Stromverbrauch | 6 | GroupValueRead |   |   104 | 28.11.2020 07:24:21,883 | vom Bus |   | Niedrig | 1.0.80 | Plug-01-IP | 1/3/80 | Portabel - Plug-01 - Stromverbrauch | 5 | GroupValueResponse | 14.056 Leistung (W) | 00 00 00 00 | 0 W 105 | 28.11.2020 07:24:22,056 | zum Bus |   | Niedrig | 1.1.13 |   | 1/3/80 | Portabel - Plug-01 - Stromverbrauch | 6 | GroupValueRead |   |   106 | 28.11.2020 07:24:22,091 | vom Bus |   | Niedrig | 1.0.80 | Plug-01-IP | 1/3/80 | Portabel - Plug-01 - Stromverbrauch | 5 | GroupValueResponse | 14.056 Leistung (W) | 00 00 00 00 | 0 W 107 | 28.11.2020 07:24:22,753 | zum Bus |   | Niedrig | 1.1.13 |   | 1/3/80 | Portabel - Plug-01 - Stromverbrauch | 6 | GroupValueRead |   |   108 | 28.11.2020 07:24:23,272 | zum Bus |   | Niedrig | 1.1.13 |   | 1/3/80 | Portabel - Plug-01 - Stromverbrauch | 6 | GroupValueRead |   |   109 | 28.11.2020 07:24:23,631 | zum Bus |   | Niedrig | 1.1.13 |   | 1/3/80 | Portabel - Plug-01 - Stromverbrauch | 6 | GroupValueRead |   |   110 | 28.11.2020 07:24:23,912 | zum Bus |   | Niedrig | 1.1.13 |   | 1/3/80 | Portabel - Plug-01 - Stromverbrauch | 6 | GroupValueRead |   |   111 | 28.11.2020 07:24:24,182 | zum Bus |   | Niedrig | 1.1.13 |   | 1/3/80 | Portabel - Plug-01 - Stromverbrauch | 6 | GroupValueRead |   |   112 | 28.11.2020 07:24:24,408 | zum Bus |   | Niedrig | 1.1.13 |   | 1/3/80 | Portabel - Plug-01 - Stromverbrauch | 6 | GroupValueRead |   |   113 | 28.11.2020 07:24:24,655 | zum Bus |   | Niedrig | 1.1.13 |   | 1/3/80 | Portabel - Plug-01 - Stromverbrauch | 6 | GroupValueRead |   |   114 | 28.11.2020 07:24:24,731 | vom Bus |   | Niedrig | 1.0.80 | Plug-01-IP | 1/3/80 | Portabel - Plug-01 - Stromverbrauch | 5 | GroupValueResponse | 14.056 Leistung (W) | 00 00 00 00 | 0 W 115 | 28.11.2020 07:24:24,880 | zum Bus |   | Niedrig | 1.1.13 |   | 1/3/80 | Portabel - Plug-01 - Stromverbrauch | 6 | GroupValueRead |   |   116 | 28.11.2020 07:24:25,094 | zum Bus |   | Niedrig | 1.1.13 |   | 1/3/80 | Portabel - Plug-01 - Stromverbrauch | 6 | GroupValueRead |   |   117 | 28.11.2020 07:24:29,600 | vom Bus |   | Niedrig | 1.0.80 | Plug-01-IP | 1/3/80 | Portabel - Plug-01 - Stromverbrauch | 5 | GroupValueWrite | 14.056 Leistung (W) | 00 00 00 00 | 0 W 118 | 28.11.2020 07:24:30,550 | zum Bus |   | Niedrig | 1.1.13 |   | 1/2/80 | Portabel - Plug-01 - Status Schalten | 6 | GroupValueRead |   |   119 | 28.11.2020 07:24:30,611 | vom Bus |   | Niedrig | 1.0.80 | Plug-01-IP | 1/2/80 | Portabel - Plug-01 - Status Schalten | 5 | GroupValueResponse | 1.011 Status | $00 | Inaktiv

`

PS: Just for testing and to be sure I have temporarily enable "KNX communication enhancement". But this does not solve the problem. The result is again, that only very few read-requests are answered, but then, the answer is just send (and received by KNX) three times (so the problem is definietely not caused by "lost" messages).

ascillato commented 3 years ago

So if I send a couple of read requests, I get a response after a couple of tries... I see in the Plug-Console that all Read-Requests are received, but only very few are answered. This is completely different to the on/off state, there, really every read-request is answered immediately

Ok. This is weird. I couldn't reproduce it. Let's do some more testing and investigation.

Let's try to answer the power request but using rules. The rules below should work similar to REPLY POWER of the KNX menu. So, with this test we should see if there is any hidden issues with the reply power or something weird on the reply telegram:

After all these settings, please restart your device in order to start from scratch and with all variables set.

On a reading request, this rule should answer the same value that was sent in the last telemetry message.

Please, test it and post the output of the console. Thanks.

martiko70 commented 3 years ago

Good morning, thanks again for your support!

With this rule it is working correctly, here are the logs:

07:55:08 RUL: TELE-ENERGY#POWER performs "var1 0"
07:55:08 SRC: Rule
07:55:08 CMD: Group 0, Index 1, Command "VAR", Data "0"
07:55:08 RSL: RESULT = {"Var1":"0"}
07:55:20 KNX: Received from 1.3.80 Command Read: 0 to KNX RX 1
07:55:20 SRC: Knx
07:55:20 CMD: Group 0, Index 1, Command "EVENT", Data "KNXRX_REQ1"
07:55:20 RSL: RESULT = {"Event":"Done"}
07:55:20 RUL: EVENT#KNXRX_REQ1 performs "KNXTX_VAL1 0"
07:55:20 SRC: Rule
07:55:20 CMD: Group 0, Index 1, Command "KNXTX_VAL", Data "0"
07:55:20 KNX: KNX TX 1 = 0.00 sent to 1.3.80
07:55:20 RSL: RESULT = {"KnxTx_Val1":"0.00"}
07:55:23 WIF: Checking connection...
# | Zeit | Dienst | Flags | Prio | Quelladresse | Quellname | Zieladresse | Zielname | Rout | Typ | DPT | Info
-- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | --
3 | 30.11.2020 07:54:47,891 | zum Bus |   | Niedrig | 1.1.13 |   | 1/3/80 | Portabel - Plug-01 - Stromverbrauch | 6 | GroupValueRead |   |  
4 | 30.11.2020 07:54:47,974 | vom Bus |   | Niedrig | 1.0.80 | Plug-01-IP | 1/3/80 | Portabel - Plug-01 - Stromverbrauch | 5 | GroupValueWrite | 14.056 Leistung (W) | 00 00 00 00 \| 0 W
5 | 30.11.2020 07:54:52,386 | zum Bus |   | Niedrig | 1.1.13 |   | 1/3/80 | Portabel - Plug-01 - Stromverbrauch | 6 | GroupValueRead |   |  
6 | 30.11.2020 07:54:52,478 | vom Bus |   | Niedrig | 1.0.80 | Plug-01-IP | 1/3/80 | Portabel - Plug-01 - Stromverbrauch | 5 | GroupValueWrite | 14.056 Leistung (W) | 00 00 00 00 \| 0 W
7 | 30.11.2020 07:54:59,760 | vom Bus |   | Niedrig | 1.1.2 |   | 0/4/21 | Zeit/Datum - Status | 6 | GroupValueWrite | 19.001 Datum/Zeit | 78 0B 1E 27 37 00 20 00 \| Montag, 30.11.2020, 07:55:00 (--V------) = (Fault: Normal (no fault), Working Day: Bank Holiday (No working day), No WD: WD field not valid, No Year: Year field valid, No Date: Month and Day of Month fields valid, No Day of Week: Day of week field valid, No Time: Hour of day, Minutes and Seconds field valid, Standard Summer Time: Time = UT+X, Qualitiy of clock: clock without ext. sync signal)
8 | 30.11.2020 07:55:20,126 | zum Bus |   | Niedrig | 1.1.13 |   | 1/3/80 | Portabel - Plug-01 - Stromverbrauch | 6 | GroupValueRead |   |  
9 | 30.11.2020 07:55:20,211 | vom Bus |   | Niedrig | 1.0.80 | Plug-01-IP | 1/3/80 | Portabel - Plug-01 - Stromverbrauch | 5 | GroupValueWrite | 14.056 Leistung (W) | 00 00 00 00 \| 0 W
10 | 30.11.2020 07:55:59,762 | vom Bus |   | Niedrig | 1.1.2 |   | 0/4/21 | Zeit/Datum - Status | 6 | GroupValueWrite | 19.001 Datum/Zeit | 78 0B 1E 27 38 00 20 00 \| Montag, 30.11.2020, 07:56:00 (--V------) = (Fault: Normal (no fault), Working Day: Bank Holiday (No working day), No WD: WD field not valid, No Year: Year field valid, No Date: Month and Day of Month fields valid, No Day of Week: Day of week field valid, No Time: Hour of day, Minutes and Seconds field valid, Standard Summer Time: Time = UT+X, Qualitiy of clock: clock without ext. sync signal)

But now, the periodic sent is not done (which is clear, als power is not configured as KNX output directly) and - as you mentioned - not the current power is sent but the one from the last telemetry message (which has in my case a delay of 2 Minutes.

But does thiis help you to fix my issue?

ascillato2 commented 3 years ago

But does thiis help you to fix my issue?

Yes. I have to do more testings but I think I have found the bug.

With this rule, it is never missed a reply?

martiko70 commented 3 years ago

Yes. I have to do more testings but I think I have found the bug.

That sounds very good! 👍

With this rule, it is never missed a reply?

Correct, I immediately received a reply for each read-request

pfisterer commented 3 years ago

@ascillato2 Thanks for looking at the other issue #10019. Do you think this is related?

martiko70 commented 3 years ago

@ascillato2 Just let me know when you have a version ready for testing...

martiko70 commented 3 years ago

@ascillato2 Any news on this topic? ;-)

ascillato2 commented 3 years ago

@martiko70

Hi,

Thanks for the reminder. Don't worry I didn't forget about this. I want to do it.

It is just that I haven't had the time for this. I have put the label "work in progress" because is the next thing I will work on. I have to pay the bills, so my job goes first and then, when I have some free time, I will work on this just for the fun of it.

I will do it ASAP.

martiko70 commented 3 years ago

Hi @ascillato2 first of all a happy new year to you!

Sorry, I did not intend to stress you, I know that you are doing it as a hobby... and I am surely not skilled enough to correct or implemtn it on my own...

So please don't misunderstand my additional questions (the 2nd is not even directly connected to this issues):

  1. Is the latest version 9.2.0 already including a bugfix (I think this request was mentioned in the changelog...)
  2. I now added a powerstrip with 4 circuits which can be switched seperatly, to use this with KNX, I need several Group Addresses to sent or receive data. It looks as if there is a hard limit of 10 GAs for sent and 10 GAs for read, at least I was not able to add more using the configuration menu. Is this a hard restriction?

Thanks again for your great work und your support!

ascillato commented 3 years ago

Hi,

Happy new year!

1- The latest version includes the read request for power but the bug explained here (that is not always answered) is not fixed yet. I'm working on it. Didn't have the time to finish the tests and make the PR.

2- The limit of 10 GA is hard coded due to it uses a fixed settings flash area and RAM. Just changing the #defines will corrupt your settings. I'm working also in a full refactoring of the KNX driver to reduce the flash and RAM usage and adding more versatility on the options. Stay tuned.

ascillato commented 3 years ago

Hi @martiko70,

Can you test latest version http://ota.tasmota.com/tasmota/tasmota-knx.bin.gz ?

Thanks

martiko70 commented 3 years ago

Hi @ascillato thanks for your update.

Unfortunately, the behaviour is exactly as before... I don't get a response except I "spam" the read requests, then every 5-10 requests, I get a response...

On the console, I don't see a difference, when a repsonse is sent, in this example, I received a response approximately in the middle of the requests:

17:40:28.522 KNX: Received from 1.3.180 Command Read: 0 to Reply Power
17:40:28.725 KNX: Received from 1.3.180 Command Read: 0 to Reply Power
17:40:28.875 KNX: Received from 1.3.180 Command Read: 0 to Reply Power
17:40:29.075 KNX: Received from 1.3.180 Command Read: 0 to Reply Power
17:40:29.175 KNX: Received from 1.3.180 Command Read: 0 to Reply Power
17:40:29.376 KNX: Received from 1.3.180 Command Read: 0 to Reply Power
17:40:29.526 KNX: Received from 1.3.180 Command Read: 0 to Reply Power
17:40:29.725 KNX: Received from 1.3.180 Command Read: 0 to Reply Power
17:40:29.875 KNX: Received from 1.3.180 Command Read: 0 to Reply Power
17:40:30.076 KNX: Received from 1.3.180 Command Read: 0 to Reply Power
17:40:30.226 KNX: Received from 1.3.180 Command Read: 0 to Reply Power

PS: The Tasmota-Version is:

Program Version | 9.3.1.3(knx)
-- | --
2021-04-14T15:03:37
ascillato commented 3 years ago

Thanks.

I think I have found the bug. The file here should fix your issue.

Can you try it?

I attach here also the minimal just for your convenience.

tasmota-knx.bin.gz tasmota-minimal.bin.gz

If this solves your issue I will make the PR. Thanks again for all the tests.

martiko70 commented 3 years ago

Hi @ascillato PERFECT! The new version works fine, each read request is answered directly...

Thanks for you great work!

So I assume that this bugfix will be integrated in the next release?

Best regards Martin

ascillato commented 3 years ago

Great. PR on its way......

So I assume that this bugfix will be integrated in the next release?

Yes. 😄

martiko70 commented 3 years ago

Again many thanks to you @ascillato , so I close this Topic...

martiko70 commented 3 years ago

Just to be sure that I did not miss it in the changelog, this bugfix is not includedin the liest Release Tasmota v9.4.0 Leslie, right?

ascillato commented 3 years ago

It is included

martiko70 commented 3 years ago

Great, I just installed the update and can confirm that it's working perfectly!

Many thanks for your support!