Tasmota icon indicating copy to clipboard operation
Tasmota copied to clipboard
verified publisher icon arendst

No reaction to KNX commands after x days

Open rolandunterholzer opened this issue 1 year ago • 25 comments

PROBLEM DESCRIPTION

When using Shelly Plus 1PM with Tasmota 14.2.0.6 (6fa38e4-solo1) there is no reaction to KNX command after some days. After restarting the device via Web-Interface everything is working again.

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 discussions
  • [x] Searched the problem in the docs
  • [x] Searched the problem in the chat
  • [x] Device used (e.g., Sonoff Basic): Shelly Plus 1 PM
  • [x] Tasmota binary firmware version number used: Tasmota 14.2.0.6 (6fa38e4-solo1)
    • [x] Pre-compiled
    • [ ] Self-compiled
  • [x] Flashing tools used: via OTA Url
  • [x] Provide the output of command: Backlog Template; Module; GPIO 255:
  Configuration output here:
11:06:03.390 MQT: stat/TasmotaFlurNord/RESULT = {"NAME":"Shelly Plus 1PM","GPIO":[0,0,0,0,192,2720,0,0,0,0,0,0,0,0,2656,0,0,0,0,2624,0,32,224,0,0,0,0,0,4736,0,0,0,0,0,0,0],"FLAG":0,"BASE":1}
11:06:03.613 MQT: stat/TasmotaFlurNord/RESULT = {"Module":{"0":"Shelly Plus 1PM"}}
11:06:03.823 MQT: stat/TasmotaFlurNord/RESULT = {"GPIO0":{"0":"None"},"GPIO1":{"0":"None"},"GPIO2":{"0":"None"},"GPIO3":{"0":"None"},"GPIO4":{"192":"Switch_n1"},"GPIO5":{"2720":"BL0937 CF"},"GPIO6":{"0":"None"},"GPIO7":{"0":"None"},"GPIO8":{"0":"None"},"GPIO9":{"0":"None"},"GPIO10":{"0":"None"},"GPIO11":{"0":"None"},"GPIO12":{"0":"None"},"GPIO13":{"0":"None"},"GPIO14":{"0":"None"},"GPIO15":{"0":"None"},"GPIO16":{"0":"None"},"GPIO17":{"0":"None"},"GPIO18":{"2656":"HLWBL CF1"},"GPIO19":{"0":"None"},"GPIO20":{"0":"None"},"GPIO21":{"0":"None"},"GPIO22":{"0":"None"},"GPIO23":{"2624":"HLWBL SEL_i"},"GPIO24":{"0":"None"},"GPIO25":{"32":"Button1"},"GPIO26":{"224":"Relay1"},"GPIO27":{"0":"None"},"GPIO32":{"4736":"ADC Temp1"},"GPIO33":{"0":"None"},"GPIO34":{"0":"None"},"GPIO35":{"0":"None"},"GPIO36":{"0":"None"},"GPIO37":{"0":"None"},"GPIO38":{"0":"None"},"GPIO39":{"0":"None"}}
  • [ ] If using rules, provide the output of this command: Backlog Rule1; Rule2; Rule3:
  Rules output here:
  • [x] Provide the output of this command: Status 0:
  STATUS 0 output here:
11:07:00.564 MQT: stat/TasmotaFlurNord/STATUS = {"Status":{"Module":0,"DeviceName":"TasmotaFlurNord","FriendlyName":["TasmotaFlurNord"],"Topic":"TasmotaFlurNord","ButtonTopic":"0","Power":"1","PowerLock":"0","PowerOnState":3,"LedState":1,"LedMask":"FFFF","SaveData":0,"SaveState":1,"SwitchTopic":"0","SwitchMode":[0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0],"ButtonRetain":0,"SwitchRetain":0,"SensorRetain":0,"PowerRetain":0,"InfoRetain":0,"StateRetain":0,"StatusRetain":0}}
11:07:00.627 MQT: stat/TasmotaFlurNord/STATUS1 = {"StatusPRM":{"Baudrate":115200,"SerialConfig":"8N1","GroupTopic":"tasmotas","OtaUrl":"https://ota.tasmota.com/tasmota32/tasmota32solo1.bin","RestartReason":"Software reset CPU","Uptime":"0T00:10:25","StartupUTC":"2024-10-06T08:56:35","Sleep":50,"CfgHolder":4617,"BootCount":18,"BCResetTime":"2024-09-15T09:12:05","SaveCount":79}}
11:07:00.676 MQT: stat/TasmotaFlurNord/STATUS2 = {"StatusFWR":{"Version":"14.2.0.6(6fa38e4-solo1)single-core","BuildDateTime":"2024-09-30T09:26:03","Core":"3_1_0","SDK":"5.3.1.240924","CpuFrequency":240,"Hardware":"ESP32-U4WDH-D v3.1","CR":"462/699"}}
11:07:00.710 MQT: stat/TasmotaFlurNord/STATUS3 = {"StatusLOG":{"SerialLog":2,"WebLog":2,"MqttLog":0,"SysLog":4,"LogHost":"10.0.0.125","LogPort":1517,"SSId":["UNTERHOLZER",""],"TelePeriod":300,"Resolution":"558580C0","SetOption":["02008009","2805C80001000600003C5A0A192800000000","00000088","00006000","00004000","00000000"]}}
11:07:00.757 MQT: stat/TasmotaFlurNord/STATUS4 = {"StatusMEM":{"ProgramSize":1960,"Free":791,"Heap":150,"StackLowMark":3,"PsrMax":0,"PsrFree":0,"ProgramFlashSize":4096,"FlashSize":4096,"FlashChipId":"164020","FlashFrequency":80,"FlashMode":"DIO","Features":["0809","9F9AD7DF","0015A001","B7F7BFCF","05DA9BC4","E0360DC7","480840D2","20200000","D4BC482D","810A80B1","00000014"],"Drivers":"1,2,3,!4,!5,7,!8,9,10,11,12,!14,!16,!17,!20,!21,!24,26,!27,29,!34,!35,38,50,52,!59,!60,62,!63,!66,!67,!68,!73,82,!86,!87,!88,!121","Sensors":"1,2,3,5,6,7,8,9,10,11,12,13,14,15,17,18,19,20,21,22,26,31,34,37,39,40,42,43,45,51,52,55,56,58,59,64,66,67,74,85,92,95,98,103,105,109,127","I2CDriver":"7,8,9,10,11,12,13,14,15,17,18,20,24,29,31,36,41,42,44,46,48,58,62,65,69,76,77,82,89"}}
11:07:00.842 MQT: stat/TasmotaFlurNord/STATUS5 = {"StatusNET":{"Hostname":"TasmotaFlurNord","IPAddress":"10.0.0.13","Gateway":"10.0.0.254","Subnetmask":"255.255.255.0","DNSServer1":"10.0.0.110","DNSServer2":"10.0.0.111","Mac":"FC:B4:67:27:94:74","IP6Global":"","IP6Local":"fe80::feb4:67ff:fe27:9474%st1","Ethernet":{"Hostname":"","IPAddress":"0.0.0.0","Gateway":"0.0.0.0","Subnetmask":"0.0.0.0","DNSServer1":"10.0.0.110","DNSServer2":"10.0.0.111","Mac":"00:00:00:00:00:00","IP6Global":"","IP6Local":""},"Webserver":2,"HTTP_API":1,"WifiConfig":4,"WifiPower":17.0}}
11:07:00.901 MQT: stat/TasmotaFlurNord/STATUS6 = {"StatusMQT":{"MqttHost":"10.0.0.124","MqttPort":1883,"MqttClientMask":"DVES_%06X","MqttClient":"DVES_279474","MqttUser":"DVES_USER","MqttCount":1,"MAX_PACKET_SIZE":1200,"KEEPALIVE":30,"SOCKET_TIMEOUT":4}}
11:07:00.938 MQT: stat/TasmotaFlurNord/STATUS7 = {"StatusTIM":{"UTC":"2024-10-06T09:07:00Z","Local":"2024-10-06T11:07:00","StartDST":"2024-03-31T02:00:00","EndDST":"2024-10-27T03:00:00","Timezone":99,"Sunrise":"07:58","Sunset":"19:17"}}
11:07:00.963 MQT: stat/TasmotaFlurNord/STATUS9 = {"StatusPTH":{"PowerDelta":0,"PowerLow":0,"PowerHigh":0,"VoltageLow":0,"VoltageHigh":0,"CurrentLow":0,"CurrentHigh":0,"MaxPower":0,"MaxPowerHold":10,"MaxPowerWindow":30,"MaxEnergy":0,"MaxEnergyStart":0}}
11:07:01.005 MQT: stat/TasmotaFlurNord/STATUS10 = {"StatusSNS":{"Time":"2024-10-06T11:07:00","Switch1":"OFF","ANALOG":{"Temperature1":41.6},"ENERGY":{"TotalStartTime":"2024-09-15T09:18:09","Total":0.015,"Yesterday":0.000,"Today":0.000,"Power":0,"ApparentPower":0,"ReactivePower":0,"Factor":0.00,"Voltage":228.40,"Current":0.000},"TempUnit":"C"}}
11:07:01.044 MQT: stat/TasmotaFlurNord/STATUS11 = {"StatusSTS":{"Time":"2024-10-06T11:07:01","Uptime":"0T00:10:26","UptimeSec":626,"Heap":148,"SleepMode":"Dynamic","Sleep":50,"LoadAvg":19,"MqttCount":1,"Berry":{"HeapUsed":23,"Objects":306},"POWER":"ON","Wifi":{"AP":1,"SSId":"UNTERHOLZER","BSSId":"54:4A:00:BF:C8:50","Channel":13,"Mode":"HT40","RSSI":48,"Signal":-76,"LinkCount":1,"Downtime":"0T00:00:03"}}}
  • [x] Set weblog to 4 and then, when you experience your issue, provide the output of the Console log:
  Console output here:

TO REPRODUCE

Steps to reproduce the behavior:

  1. Restart device
  2. Wait some days (3-7)
  3. Send KNX write to the defined "Group Addresses to Receive Data from"
  4. The device does not toggle the output

EXPECTED BEHAVIOUR

A clear and concise description of what you expected to happen. After receiving KNX write on the defined "Group Addresses to Receive Data from" the output should toggle to ON/OFF regarding the KNX write command

SCREENSHOTS

If applicable, add screenshots to help explain your problem.

ADDITIONAL CONTEXT

Add any other context about the problem here.

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

rolandunterholzer avatar Oct 06 '24 09:10 rolandunterholzer

What does the KNX configuration look like?

Noschvie avatar Oct 07 '24 08:10 Noschvie

knx_config

Is there a possibility to debug KNX in detail at the Tasmota Device? With logLevel 4 activated I can't see any info that a KNX packet was received when the device is in the state of not acting to the messages. After a restart it looks fine: knx_log

rolandunterholzer avatar Oct 07 '24 10:10 rolandunterholzer

With logLevel 4 activated I can't see any info that a KNX packet was received

At 13:08:04.633 you have a sample log for a incoming KNX packet

when the device is in the state of not acting to the messages

I don't understand that part of your message

May be you could run Wireshark on a computer to track all KNX packets on the network

barbudor avatar Oct 07 '24 19:10 barbudor

With logLevel 4 activated I can't see any info that a KNX packet was received

At 13:08:04.633 you have a sample log for a incoming KNX packet

please read carefully: image

when the device is in the state of not acting to the messages

I don't understand that part of your message

May be you could run Wireshark on a computer to track all KNX packets on the network

In other words: after some days the device stops toggling the output in regards of the KNX packets sent

I think Wireshark would not help here because: a) I can see the KNX packets within ETS GroupMonitor b) After a restart of the device, the KNX packets are handled as supposed => the only thing that changes in my environemt with a restart of device is the device/runstate itself

rolandunterholzer avatar Oct 10 '24 08:10 rolandunterholzer

I'm having a very similar problem, same device but with matter, after one day working properly it become not responding in Apple Home App. Reboot via web interface fixes it temporarily.

bmpalmeida avatar Oct 21 '24 23:10 bmpalmeida

I have now started a test with an "Athom LB017W" that visualizes the status of a KNX status address. This means that a KNX address was linked to “Output 1”. This KNX status address will be triggerd by an KNX actor (Light in the staircase).

Noschvie avatar Oct 27 '24 11:10 Noschvie

My test with the "Athom LB017W" running Tasmota 14.3.0 (release-knx) is working and has Uptime 5T08:46:41

Noschvie avatar Nov 01 '24 19:11 Noschvie

If I'm not wrong your device has an ESP8266 chip whereas the Shelly has an ESP32. So the releases are different. I have other devices with the ESP8266 release that work without any problems. So wether it is the ESP32 release or the shelly device itself...

rolandunterholzer avatar Nov 02 '24 08:11 rolandunterholzer

Can also use a Shelly Plus 1 or Shelly 1 Mini Gen3 for testing, which do you prefer?

Noschvie avatar Nov 02 '24 09:11 Noschvie

If Shelly Plus 1 is also based on ESP32? --> please test that on. Thank You

rolandunterholzer avatar Nov 06 '24 14:11 rolandunterholzer

Started the test with an "Athom Plug V3" / ESP32-C3 v0.4 running v 14.3.0 on Tuesday.

Noschvie avatar Nov 07 '24 06:11 Noschvie

This issue can be reproduced with the "Athom Plug V3" / ESP32-C3. The KNX: Received from 1/4/47 Command Write: 1 to Output 1 message is missing in the log.

Noschvie avatar Nov 08 '24 17:11 Noschvie

Currently as a workaround I restart the Shelly Plus 1PM every day by rule on 03:00. Will this somehow harm the device?

{"Rule1":{"State":"ON","Once":"OFF","StopOnError":"OFF","Length":35,"Free":476,"Rules":"on clock#timer=1 do restart 1 endon"}}

rolandunterholzer avatar Nov 11 '24 14:11 rolandunterholzer

This issue has been automatically marked as stale because it hasn't any activity in last few weeks. It will be closed if no further activity occurs. Thank you for your contributions.

github-actions[bot] avatar Dec 06 '24 14:12 github-actions[bot]

Revive.

arendst avatar Dec 06 '24 14:12 arendst

I'm currently testing this. I had a lot of trouble to get KNX going in the first place.

Finally, after disabling AP IGMP Snooping I managed to receive some commands. Alas after ten minutes that stopped working. I just disabled Wireless Meshing hoping to fix the issue.

Continue testing.....

arendst avatar Dec 06 '24 14:12 arendst

Haven't seen the issue yet but in the meantime I extended command Knx_Enabled with the option to restart UDP multicast if KNX is re-enabled.

So in case of not receiving KNX commands anymore, instead of a restart, try this:

knx_enabled 0
knx_enabled 1

If it solves the connection problem pls let me know.

arendst avatar Dec 06 '24 16:12 arendst

@arendst Hello Theo updated the "Athom Plug V3" / ESP32-C3 with latest dev version yesterday and it works in sync with the "Athom LB017W" running Tasmota 14.3.0 (release-knx) for a few hours. This morning I used

knx_enabled 0
knx_enabled 1

and it solves the connection problem for the moment.

Noschvie avatar Dec 07 '24 09:12 Noschvie

Thx for the feedback. Finding the cause will be difficult.

arendst avatar Dec 07 '24 10:12 arendst

Pls try latest dev. This adds an udp.flush() fixing possible miscommunications.

arendst avatar Dec 07 '24 11:12 arendst

same behavior as before,

knx_enabled 0
knx_enabled 1

is needed to retrigger the communication.

Noschvie avatar Dec 07 '24 21:12 Noschvie

Bugger.

As I cannot reproduce (other than that my ubiquiti system refuses to perform multicast most of the time) I suggest you use a rule to regularly perfrom the above commands until someone finds the root cause of this.

BTW it would be great if we could rule out either ESP8266 or ESP32.

arendst avatar Dec 07 '24 21:12 arendst

After

knx_enabled 0
knx_enabled 1

was executed once at the "Athom Plug V3" / ESP32-C3 yesterday, the communication seems to have been working since then.

Noschvie avatar Dec 08 '24 17:12 Noschvie

@Noschvie pls keep me posted when it fails again.

arendst avatar Dec 09 '24 14:12 arendst

the "Athom Plug V3" / ESP32-C3 was working just before update to 14.4.0 Executing

knx_enabled 0
knx_enabled 1

and it‘s working again.

Noschvie avatar Dec 12 '24 06:12 Noschvie

It seems that the wifi connection is crucial… I placed the ESP32 socket closer to the AP and now the KNX telegrams are received more reliably. The device with the ESP8266 does not seem to be as sensitive.

Noschvie avatar Jan 03 '25 15:01 Noschvie

I have an ESP8266 (Sonoff T1) with the same issue. On v12 KNX was working fine, on v14.4.1 it stops working after a while. Also a same hw with v12 works flawlessly. WiFi is ubiquiti. Let me know if I can help in debugging.

krishy2 avatar Jan 06 '25 21:01 krishy2

Do anyone know how much time the multicast registration should stay active when a router receives it? Is there a way to discover this without logging inside the router?

I saw on Google some sources saying "30-3000 sec, usually 300", but seems inconclusive.

Asking because this may because a network behavior, not Tasmota itself.

alanjds avatar Jan 08 '25 18:01 alanjds

Theo did mention his Ubiquity network stuff seemed to have a registration TTL (or whatever it is called) of about 10 minutes. I know some HP Aruba switches typically lost a multicast registratoin after 5 minutes, when there was no querier active.

TD-er avatar Jan 08 '25 20:01 TD-er

This issue has been automatically marked as stale because it hasn't any activity in last few weeks. It will be closed if no further activity occurs. Thank you for your contributions.

github-actions[bot] avatar Feb 02 '25 21:02 github-actions[bot]