Tasmota: KNX Read reply for Power not working

Created on 5 Sep 2020  路  28Comments  路  Source: arendst/Tasmota

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!_

  • [X] Read the Contributing Guide and Policy and the Code of Conduct
  • [X] Searched the problem in issues
  • [X] Searched the problem in the docs
  • [X] Searched the problem in the forum
  • [X] Searched the problem in the chat
  • [X] Device used (e.g., Sonoff Basic): Gosund SP111
  • [X] Tasmota binary firmware version number used: 8.4.0 KNX

    • [X] Pre-compiled

    • [ ] Self-compiled

    • [ ] IDE / Compiler used: _____

  • [X] Flashing tools used: initially Tuya Convert (Update to 8.4.0 KNX via OTA)
  • [X] Provide the output of command: Backlog Template; Module; GPIO 255:
05:41:24 RSL: RESULT = {"NAME":"SP111 v1.1","GPIO":[56,0,158,0,132,134,0,0,131,17,0,21,0],"FLAG":0,"BASE":45}
05:41:24 RSL: RESULT = {"Module":{"0":"SP111 v1.1"}}
05:41:24 RSL: RESULT = {"GPIO0":{"56":"Led1i"},"GPIO1":{"0":"None"},"GPIO2":{"158":"LedLinki"},"GPIO3":{"0":"None"},"GPIO4":{"132":"HLWBL CF1"},"GPIO5":{"134":"BL0937 CF"},"GPIO9":{"0":"None"},"GPIO10":{"0":"None"},"GPIO12":{"131":"HLWBL SELi"},"GPIO13":{"17":"Button1"},"GPIO14":{"0":"None"},"GPIO15":{"21":"Relay1"},"GPIO16":{"0":"None"}}
  • [X] If using rules, provide the output of this command: Backlog Rule1; Rule2; Rule3:
    No Rules used

  • [X] Provide the output of this command: Status 0:

05:42:33 CMD: Status 0
05:42:33 RSL: STATUS = {"Status":{"Module":0,"DeviceName":"Plug-01","FriendlyName":["Plug-01"],"Topic":"tasmota","ButtonTopic":"0","Power":0,"PowerOnState":3,"LedState":1,"LedMask":"FFFF","SaveData":1,"SaveState":1,"SwitchTopic":"0","SwitchMode":[0,0,0,0,0,0,0,0],"ButtonRetain":0,"SwitchRetain":0,"SensorRetain":0,"PowerRetain":0}}
05:42:33 RSL: STATUS1 = {"StatusPRM":{"Baudrate":115200,"SerialConfig":"8N1","GroupTopic":"tasmotas","OtaUrl":"http://thehackbox.org/tasmota/release/tasmota-knx.bin","RestartReason":"Software/System restart","Uptime":"17T14:59:36","StartupUTC":"2020-08-18T13:42:57","Sleep":50,"CfgHolder":4617,"BootCount":28,"BCResetTime":"2020-08-01T13:44:44","SaveCount":288,"SaveAddress":"F8000"}}
05:42:33 RSL: STATUS2 = {"StatusFWR":{"Version":"8.4.0(knx)","BuildDateTime":"2020-07-29T12:07:24","Boot":31,"Core":"2_7_2_1","SDK":"2.2.2-dev(38a443e)","CpuFrequency":80,"Hardware":"ESP8285","CR":"384/699"}}
05:42:33 RSL: STATUS3 = {"StatusLOG":{"SerialLog":2,"WebLog":2,"MqttLog":0,"SysLog":0,"LogHost":"","LogPort":514,"SSId":["koe",""],"TelePeriod":120,"Resolution":"558180C0","SetOption":["02008001","2805C8000100060000005A00000000000000","00000000","00006000"]}}
05:42:33 RSL: STATUS4 = {"StatusMEM":{"ProgramSize":593,"Free":408,"Heap":22,"ProgramFlashSize":1024,"FlashSize":1024,"FlashChipId":"144051","FlashFrequency":40,"FlashMode":3,"Features":["00000809","9FDAE597","04268011","000000CD","010013C0","8000F181","00004004"],"Drivers":"1,2,3,4,5,6,7,8,9,10,11,12,16,18,19,22,24,26,27,30,35,37","Sensors":"1,2,3,4,5,6"}}
05:42:33 RSL: STATUS5 = {"StatusNET":{"Hostname":"Plug-01","IPAddress":"192.168.28.80","Gateway":"192.168.28.1","Subnetmask":"255.255.255.0","DNSServer":"192.168.28.1","Mac":"E0:98:06:C6:64:A7","Webserver":2,"WifiConfig":2,"WifiPower":17.0}}
05:42:33 RSL: STATUS7 = {"StatusTIM":{"UTC":"2020-09-05T04:42:33","Local":"2020-09-05T05:42:33","StartDST":"2020-03-29T02:00:00","EndDST":"2020-10-25T03:00:00","Timezone":"+01:00","Sunrise":"06:13","Sunset":"19:23"}}
05:42:33 RSL: STATUS9 = {"StatusPTH":{"PowerDelta":0,"PowerLow":0,"PowerHigh":0,"VoltageLow":0,"VoltageHigh":0,"CurrentLow":0,"CurrentHigh":0}}
05:42:33 RSL: STATUS10 = {"StatusSNS":{"Time":"2020-09-05T05:42:33","ENERGY":{"TotalStartTime":"2020-08-01T13:37:20","Total":0.059,"Yesterday":0.011,"Today":0.000,"Power":0,"ApparentPower":0,"ReactivePower":0,"Factor":0.00,"Voltage":0,"Current":0.000}}}
05:42:33 RSL: STATUS11 = {"StatusSTS":{"Time":"2020-09-05T05:42:33","Uptime":"17T14:59:36","UptimeSec":1522776,"Heap":22,"SleepMode":"Dynamic","Sleep":50,"LoadAvg":19,"MqttCount":0,"POWER":"OFF","Wifi":{"AP":1,"SSId":"koe","BSSId":"E0:28:6D:73:D6:AF","Channel":6,"RSSI":100,"Signal":-46,"LinkCount":43,"Downtime":"0T00:03:33"}}}
  • [X] Provide the output of the Console log output when you experience your issue; if applicable:
    _(Please use_ weblog 4 _for more debug information)_
05:59:32 KNX: Received from 1.3.80 Command Read: 0 to Reply Power

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)

bug work in progress

Most helpful comment

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

All 28 comments

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"_

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

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?

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.

@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?

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.

@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);
}

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.

Fixed in proposed PR #9891

Sorry for the delay.

Please test. Thanks.

@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

Just install the latest Tasmota version 9.1.0.2

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

@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)

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

@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....

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

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...`

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

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

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

@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).

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:

  • In the KNX MENU delete 1/3/80 -> reply power
  • Add 1/3/80 -> knx rx 1
  • Add knx tx 1 -> 1/3/80
  • Go to the Tasmota console and type:
Rule1 1
Rule1 on event#knxrx_req1 do KNXTX_VAL1 %var1% endon on tele-energy#power do var1 %value% endon

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.

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?

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?

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

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

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

@ascillato2
Any news on this topic? ;-)

@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.

Was this page helpful?
0 / 5 - 0 ratings