New firmware not work

Hardware (please complete the following information):

Inverter model:SUN-600G3-EU.

Software (please complete the following information):

Logger firmware version: MW3_16U_5406_2.06
deye-inverter-mqtt version:latest
config.env (remove passwords before pasting):
LOG_LEVEL=INFO
LOG_STREAM=STDOUT
DEYE_DATA_READ_INTERVAL=60
DEYE_METRIC_GROUPS=micro
DEYE_LOGGER_SERIAL_NUMBER=4196253664
DEYE_LOGGER_IP_ADDRESS=<IP_ADDRESS>
DEYE_LOGGER_PORT=8899
DEYE_FEATURE_MQTT_PUBLISHER=true
DEYE_FEATURE_SET_TIME=true
MQTT_HOST=<IP_ADDRESS>
MQTT_PORT=1883
MQTT_USERNAME=mqttuser
MQTT_PASSWORD=#######ä
MQTT_TOPIC_PREFIX=deye
PATH=/usr/local/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
LANG=C.UTF-8
GPG_KEY=A035C8C19219BA821ECEA86B64E628F8D684696D
PYTHON_VERSION=3.10.10
PYTHON_PIP_VERSION=22.3.1
PYTHON_SETUPTOOLS_VERSION=65.5.1
PYTHON_GET_PIP_URL=https://github.com/pypa/get-pip/raw/d5cb0afaf23b8520f1bbcfed521017b4a95f5c01/public/get-pip.py
PYTHON_GET_PIP_SHA256=394be00f13fa1b9aaa47e911bdb59a09c3b2986472130f30aa0bfaf7f3980637

Error:
2023-09-07 15:33:49,329 - DeyeDaemon - INFO - Reading start
2023-09-07 15:33:49,329 - DeyeDaemon - INFO - Reading registers [metrics group: micro, range: 003c-0074]
2023-09-07 15:33:49,469 - DeyeModbus - ERROR - Response frame has invalid starting byte
2023-09-07 15:33:49,470 - DeyeMqttClient - INFO - Logger is offline
With Firmware 1.57 ist o.k.
Now with the new Firmware are not o.k.

Thanks for reporting the problem @Joerglp . It seems like something has changed in version 2 of the firmware. Could you enable DEBUG logs, and try again, so we can see what is returned by the logger?

2023-09-08 04:56:49,420 - DeyeDaemon - INFO - Reading start2023-09-08 04:56:49,421 - DeyeDaemon - INFO - Reading registers [metrics group: micro, range: 003c-0074]2023-09-08 04:56:51,237 - DeyeConnector - DEBUG - Request frame: a5170010450000e0bf1dfa0200000000000000000000000000000103003c003945d4b6152023-09-08 04:56:51,748 - paho.mqtt.client - DEBUG - Sending PINGREQ2023-09-08 04:56:51,749 - paho.mqtt.client - DEBUG - Received PINGRESP2023-09-08 04:56:52,033 - DeyeConnector - DEBUG - Received response frame in 1. attempt: 41542b595a434d505645523d4d57335f3136555f353430365f322e30360d0a0d0a2023-09-08 04:56:52,033 - DeyeModbus - ERROR - Response frame has invalid starting byte2023-09-08 04:56:52,034 - DeyeMqttClient - DEBUG - Publishing message. topic: 'deye/logger_status', value: 'offline'2023-09-08 04:56:52,034 - paho.mqtt.client - DEBUG - Sending PUBLISH (d0, q1, r0, m19), 'b'deye/logger_status'', ... (7 bytes)2023-09-08 04:56:52,035 - paho.mqtt.client - DEBUG - Received PUBACK (Mid: 19)2023-09-08 04:56:52,036 - DeyeMqttClient - INFO - Logger is offline2023-09-08 04:56:52,037 - DeyeDaemon - INFO - Reading completedVon meinem iPad gesendetAm 07.09.2023 um 21:39 schrieb Krzysztof Białek @.***>:
Thanks for reporting the problem @Joerglp . It seems like something has changed in version 2 of the firmware. Could you enable DEBUG logs, and try again, so we can see what is returned by the logger?
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: @.***>

The response "41542b595a434d505645523d4d57335f3136555f353430365f322e30360d0a0d0a" is a hex encoded ascii string. After conversion it looks like this "AT+YZCMPVER=MW3_16U_5406_2.06", so it's a response from the AT command interface.
Possible options:

Someone figures out how to do Modbus/TCP communication with loggers having fw v2.x
Someone implements AT command support as a replacement of Modbus/TCP. Something similar to https://github.com/jedie/inverter-connect @jedie Do you know if it's feasible and could solve the problem?

I cannot see any option to enable Modbus/TCP even in the config_hide.html.

Okay, perhaps Modbus/TCP interface has been moved to another TCP port. Can you scan your inverter IP with nmap?

No other open port on the inverter.
80/tcp   open  http       LimitlessLED smart lightbulb bridge httpd
|_http-server-header: HTTPD
| http-methods:
|_  Supported Methods: GET POST
|_http-title: 401 Unauthorized
| http-auth:
| HTTP/1.0 401 Unauthorized\x0D
|_  Basic realm=USER LOGIN
8899/tcp open  ospf-lite?
| fingerprint-strings:
|   GenericLines:
|     AT+YZCMPVER=MW3_16U_5406_2.27
|<PHONE_NUMBER>
|<PHONE_NUMBER>
|<PHONE_NUMBER>
|   GetRequest, HTTPOptions, NULL:
|     AT+YZCMPVER=MW3_16U_5406_2.27
|<PHONE_NUMBER>
|   RTSPRequest:
|     AT+YZCMPVER=MW3_16U_5406_2.27
|<PHONE_NUMBER>
|_<PHONE_NUMBER>

I can see the Entry Server and Port 8899 in the config_hide.html.
I have the Firmware 2.06

Per Telnet:
telnet <IP_ADDRESS> 8899
Connected to <IP_ADDRESS>
AT+YZCMPVER=MW3_16U_5406_2.06
��B��X#�&2211236711
�                  p
����B��Y��&2211236711
�                    p
����B�&2211236711
�                p
����B��X#^C

The big problem is, that the new SUN-MI-RELAY-01 is automatically updating the inverter to firmware version 2.27. So most of the users will have this problem in the near future.
Like me since 5 days...

Maybe these settings are helping to analyse?

@Joerglp @SMCerina Could you please check if the AT interface works with the new firmware as before? If yes, then there is a chance to use for Modbus-over-AT communication.
For that you can use this project https://github.com/s10l/deye-logger-at-cmd
Here are the results I got from my logger running firmware v1

Connectivity test:

❯ ./build/main -t <IP_ADDRESS>:48899
2023/09/09 08:46:00 * Connecting :0 -> <IP_ADDRESS>:48899...
2023/09/09 08:46:08 AP settings
2023/09/09 08:46:08 	Mode, SSID and Chanel:  11BGN,AP_XXXXXXXXX,AUTO
2023/09/09 08:46:08 	Encryption:             WPA2PSK,AES,712003b0
2023/09/09 08:46:08 Station settings
2023/09/09 08:46:08 	SSID:                   XXXXXXXXX
2023/09/09 08:46:08 	Key:                    WPA2PSK,AES,XXXXXXXXXX
2023/09/09 08:46:08 	IP:                     DHCP,<IP_ADDRESS>,<IP_ADDRESS>,<IP_ADDRESS>
2023/09/09 08:46:08 Web settings
2023/09/09 08:46:08 	Login:                  admin,admin
2023/09/09 08:46:09

Modbus read test:

❯ ./build/main -t <IP_ADDRESS>:48899 -xmb 00280001
2023/09/09 09:02:21 * Connecting :0 -> <IP_ADDRESS>:48899...
2023/09/09 09:02:24 +ok=01030204423AB50000
2023/09/09 09:02:25

@carstenfroehlich What are the options available here?

TCP-Server
TCP-Client
UDP

TCP-Server TCP-Client UDP

Exactly the same options as for my logger running on firmware v1

maybe the options of the select box have changed?
<select name="net_setting_pro_sel" id="div_5_3_tcp" style="width:250px" onclick="internetSet()">                     <option value="TCPSERVER">TCP-Server</option>                     <option value="TCPCLIENT">TCP-Client</option>                     <option value="UDP">UDP</option></select>

root@server01:~/deye-logger-at-cmd/build# ./main -t <IP_ADDRESS>:48899
2023/09/09 11:22:20 * Connecting :0 -> <IP_ADDRESS>:48899...
2023/09/09 11:22:28 AP settings
2023/09/09 11:22:28     Mode, SSID and Chanel:  11BGN,AP_4196253664,AUTO
2023/09/09 11:22:28     Encryption:             WPA2PSK,AES,847a4d1c
2023/09/09 11:22:28 Station settings
2023/09/09 11:22:28     SSID:                   Home
2023/09/09 11:22:28     Key:                    WPA2PSK,AES,9026905867692283
2023/09/09 11:22:28     IP:                     static,<IP_ADDRESS>,<IP_ADDRESS>,<IP_ADDRESS>
2023/09/09 11:22:28 Web settings
2023/09/09 11:22:28     Login:                  admin,admin
2023/09/09 11:22:29
root@server01:~/deye-logger-at-cmd/build# ./main -t <IP_ADDRESS>:48899  -xmb 00280001
2023/09/09 11:23:01 * Connecting :0 -> <IP_ADDRESS>:48899...
2023/09/09 11:23:04 +ok=0103020064B9AF
2023/09/09 11:23:05

@Joerglp Thanks. This looks very promising.

this is from my server:
go run main.go -t <IP_ADDRESS>:48899
2023/09/09 12:43:09 * Connecting :0 -> <IP_ADDRESS>:48899...
2023/09/09 12:43:17 AP settings
2023/09/09 12:43:17     Mode, SSID and Chanel:  11BGN,AP_XXXXXXX,AUTO
2023/09/09 12:43:17     Encryption:             WPA2PSK,AES,XXXXXX
2023/09/09 12:43:17 Station settings
2023/09/09 12:43:17     SSID:                   XXXXXXXXXXX
2023/09/09 12:43:17     Key:                    WPA2PSK,AES,XXXXXXXX
2023/09/09 12:43:17     IP:                     DHCP,<IP_ADDRESS>,<IP_ADDRESS>,<IP_ADDRESS>
2023/09/09 12:43:17 Web settings
2023/09/09 12:43:17     Login:                  XXXXXXX,XXXXXXXX
2023/09/09 12:43:18
go run main.go -t <IP_ADDRESS>:48899 -xmb 00280001
2023/09/09 12:46:08 * Connecting :0 -> <IP_ADDRESS>:48899...
2023/09/09 12:46:11 +ok=0103020064B9AF
2023/09/09 12:46:12

does this help?
2023-09-09 12:31:28,362 - DeyeDaemon - INFO - Reading start 2023-09-09 12:31:28,363 - DeyeDaemon - INFO - Reading registers [metrics group: micro, range: 003c-0074] 2023-09-09 12:31:28,371 - DeyeModbus - ERROR - Response frame has invalid starting byte 2023-09-09 12:31:28,375 - DeyeMqttClient - INFO - Logger is offline 2023-09-09 12:31:28,375 - DeyeDaemon - INFO - Reading completed

Your tests proven, that it's possible to use Modbus-over-AT to read the data. I've started working on that feature. Stay tuned.

It actually works with https://github.com/jedie/inverter-connect via Modbus over AT
./cli.py print-values --ip <IP_ADDRESS> --port 48899 -c

Here is a beta image that uses AT commands for communication with the inverter exclusively. ghcr.io/kbialek/deye-inverter-mqtt:2023.09.1-beta-1 Try it out.
The implementation is very hacky now. Primarily error handling is very poor. However it's ready to start collecting feedback.
No extra config changes are necessary.

Now I became that:
2023-09-09 15:43:08,215 - DeyeDaemon - INFO - Please help me build the list of compatible inverters. https://github.com/kbialek/deye-inverter-mqtt/issues/41
2023-09-09 15:43:08,215 - DeyeAtConnector - INFO - Hello
2023-09-09 15:43:08,259 - paho.mqtt.client - DEBUG - Sending CONNECT (u1, p1, wr1, wq1, wf1, c1, k60) client_id=b'deye-inverter-4196253664'
2023-09-09 15:43:08,261 - paho.mqtt.client - DEBUG - Received CONNACK (0, 0)
2023-09-09 15:43:08,262 - paho.mqtt.client - DEBUG - Sending PUBLISH (d0, q1, r1, m1), 'b'deye/status'', ... (6 bytes)
2023-09-09 15:43:08,262 - DeyeMqttClient - INFO - Successfully connected to MQTT Broker located at <IP_ADDRESS>:1883
2023-09-09 15:43:08,263 - DeyeDaemon - INFO - Feature "Report metrics over MQTT": enabled
2023-09-09 15:43:08,263 - DeyeDaemon - INFO - Feature "Set inverter time once online": enabled
2023-09-09 15:43:08,263 - DeyeDaemon - DEBUG - Start to execute the daemon at intervals of 60 seconds
2023-09-09 15:43:08,264 - DeyeDaemon - INFO - Reading start
2023-09-09 15:43:08,264 - DeyeDaemon - INFO - Reading registers [metrics group: micro, range: 003c-0074]
2023-09-09 15:43:08,265 - DeyeAtConnector - DEBUG - Sending AT command: b'WIFIKIT-214028-READ'
2023-09-09 15:43:08,265 - paho.mqtt.client - DEBUG - Received PUBACK (Mid: 1)
2023-09-09 15:43:08,766 - DeyeAtConnector - DEBUG - Received response frame in 1. attempt: b'<IP_ADDRESS>,E8FDF88E20F6,4196253664'
2023-09-09 15:43:08,766 - DeyeAtConnector - DEBUG - Sending AT command: b'+ok'
2023-09-09 15:43:09,267 - DeyeAtConnector - DEBUG - Sending AT command: b'AT+INVDATA=8,0103003c003945d4\n'
2023-09-09 15:43:09,768 - DeyeAtConnector - DEBUG - Received response frame in 1. attempt: b'+ok=01\x1003\x1072\x1000\x101D\x1000\x1000\x1000\x1000\x100F\x10F2\x1000\x1000\x1000\x100E\x1000\x100E\x1000\x1000\x1000\x1000\x1007\x10BD\x1000\x1000\x1007\x10D1\x1000\x1000\x1009\x1038\x1000\x1000\x1000\x1000\x1000\x1001\x1000\x1000\x1000\x1000\x1013\x1088\x1000\x1000\x1000\x1000\x1000\x1000\x1000\x1000\x1000\x1000\x1000\x1000\x1001\x1068\x1000\x1000\x1000\x1000\x1000\x1000\x1012\x10E8\x1000\x1000\x1000\x1000\x1000\x1000\x1000\x1000\x1000\x1000\x1000\x1000\x1000\x1000\x1000\x1000\x1000\x1000\x1000\x1000\x1000\x1000\x1000\x1000\x1000\x1000\x1000\x1000\x1000\x1000\x1000\x1000\x1000\x1000\x1000\x1000\x1000\x10EA\x1000\x1007\x1000\x10FA\x1000\x1007\x1000\x1000\x1000\x1000\x1000\x1000\x1000\x1000\x1058\x10AB\x10\r\n\r\n'
2023-09-09 15:43:09,768 - DeyeAtConnector - DEBUG - Extracted Modbus response 010372001D000000000FF20000000E000E0000000007BD000007D100000938000000000001000000001388000000000000000000000000016800000000000012E800000000000000000000000000000000000000000000000000000000000000000000000000EA000700FA00070000000000000000
2023-09-09 15:43:09,768 - DeyeAtConnector - DEBUG - Sending AT command: b'AT+Q\n'
2023-09-09 15:43:10,269 - DeyeModbus - ERROR - Modbus frame is too short
2023-09-09 15:43:10,270 - DeyeMqttClient - DEBUG - Publishing message. topic: 'deye/logger_status', value: 'offline'
2023-09-09 15:43:10,270 - paho.mqtt.client - DEBUG - Sending PUBLISH (d0, q1, r0, m2), 'b'deye/logger_status'', ... (7 bytes)
2023-09-09 15:43:10,271 - paho.mqtt.client - DEBUG - Received PUBACK (Mid: 2)
2023-09-09 15:43:10,272 - DeyeMqttClient - INFO - Logger is offline
2023-09-09 15:43:10,272 - DeyeDaemon - INFO - Reading completed
2023-09-09 15:44:08,344 - paho.mqtt.client - DEBUG - Sending PINGREQ
2023-09-09 15:44:08,375 - paho.mqtt.client - DEBUG - Received PINGRESP
2023-09-09 15:44:10,274 - DeyeDaemon - INFO - Reading start
2023-09-09 15:44:10,278 - DeyeDaemon - INFO - Reading registers [metrics group: micro, range: 003c-0074]
2023-09-09 15:44:10,279 - DeyeAtConnector - DEBUG - Sending AT command: b'WIFIKIT-214028-READ'
2023-09-09 15:44:10,781 - DeyeAtConnector - DEBUG - Received response frame in 1. attempt: b'<IP_ADDRESS>,E8FDF88E20F6,4196253664'
2023-09-09 15:44:10,781 - DeyeAtConnector - DEBUG - Sending AT command: b'+ok'
2023-09-09 15:44:11,285 - DeyeAtConnector - DEBUG - Sending AT command: b'AT+INVDATA=8,0103003c003945d4\n'
2023-09-09 15:44:11,786 - DeyeAtConnector - DEBUG - Received response frame in 1. attempt: b'+ok=01\x1003\x1072\x1000\x101D\x1000\x1000\x1000\x1000\x100F\x10F2\x1000\x1000\x1000\x100E\x1000\x100E\x1000\x1000\x1000\x1000\x1007\x10BD\x1000\x1000\x1007\x10D1\x1000\x1000\x1009\x1038\x1000\x1000\x1000\x1000\x1000\x1001\x1000\x1000\x1000\x1000\x1013\x1088\x1000\x1000\x1000\x1000\x1000\x1000\x1000\x1000\x1000\x1000\x1000\x1000\x1001\x1068\x1000\x1000\x1000\x1000\x1000\x1000\x1012\x10E8\x1000\x1000\x1000\x1000\x1000\x1000\x1000\x1000\x1000\x1000\x1000\x1000\x1000\x1000\x1000\x1000\x1000\x1000\x1000\x1000\x1000\x1000\x1000\x1000\x1000\x1000\x1000\x1000\x1000\x1000\x1000\x1000\x1000\x1000\x1000\x1000\x1000\x10EA\x1000\x1007\x1000\x10FA\x1000\x1007\x1000\x1000\x1000\x1000\x1000\x1000\x1000\x1000\x1058\x10AB\x10\r\n\r\n'
2023-09-09 15:44:11,787 - DeyeAtConnector - DEBUG - Extracted Modbus response 010372001D000000000FF20000000E000E0000000007BD000007D100000938000000000001000000001388000000000000000000000000016800000000000012E800000000000000000000000000000000000000000000000000000000000000000000000000EA000700FA00070000000000000000
2023-09-09 15:44:11,787 - DeyeAtConnector - DEBUG - Sending AT command: b'AT+Q\n'
2023-09-09 15:44:12,290 - DeyeModbus - ERROR - Modbus frame is too short
2023-09-09 15:44:12,292 - DeyeMqttClient - DEBUG - Publishing message. topic: 'deye/logger_status', value: 'offline'
2023-09-09 15:44:12,295 - paho.mqtt.client - DEBUG - Sending PUBLISH (d0, q1, r0, m3), 'b'deye/logger_status'', ... (7 bytes)
2023-09-09 15:44:12,296 - paho.mqtt.client - DEBUG - Received PUBACK (Mid: 3)
2023-09-09 15:44:12,297 - DeyeMqttClient - INFO - Logger is offline
2023-09-09 15:44:12,298 - DeyeDaemon - INFO - Reading completed
2023-09-09 15:45:08,393 - paho.mqtt.client - DEBUG - Sending PINGREQ
2023-09-09 15:45:08,395 - paho.mqtt.client - DEBUG - Received PINGRESP
2023-09-09 15:45:10,272 - DeyeDaemon - INFO - Reading start
2023-09-09 15:45:10,275 - DeyeDaemon - INFO - Reading registers [metrics group: micro, range: 003c-0074]
2023-09-09 15:45:10,275 - DeyeAtConnector - DEBUG - Sending AT command: b'WIFIKIT-214028-READ'
2023-09-09 15:45:15,780 - DeyeAtConnector - DEBUG - Connection response timeout
2023-09-09 15:45:20,784 - DeyeAtConnector - DEBUG - Connection response timeout
2023-09-09 15:45:25,788 - DeyeAtConnector - DEBUG - Connection response timeout
2023-09-09 15:45:30,793 - DeyeAtConnector - DEBUG - Connection response timeout
2023-09-09 15:45:35,798 - DeyeAtConnector - DEBUG - Connection response timeout
2023-09-09 15:45:35,798 - DeyeAtConnector - WARNING - Too many connection timeouts
2023-09-09 15:45:35,798 - DeyeAtConnector - DEBUG - Sending AT command: b'+ok'
2023-09-09 15:45:36,299 - DeyeAtConnector - DEBUG - Sending AT command: b'AT+INVDATA=8,0103003c003945d4\n'
2023-09-09 15:45:41,804 - DeyeAtConnector - DEBUG - Connection response timeout
2023-09-09 15:45:46,808 - DeyeAtConnector - DEBUG - Connection response timeout
2023-09-09 15:45:51,812 - DeyeAtConnector - DEBUG - Connection response timeout
2023-09-09 15:45:56,816 - DeyeAtConnector - DEBUG - Connection response timeout
2023-09-09 15:46:01,820 - DeyeAtConnector - DEBUG - Connection response timeout
2023-09-09 15:46:01,820 - DeyeAtConnector - WARNING - Too many connection timeouts
2023-09-09 15:46:01,820 - DeyeDaemon - ERROR - Unexpected error during daemon execution
Traceback (most recent call last):
File "/opt/deye_inverter_mqtt/deye_daemon.py", line 167, in __invoke_action
self.action()
File "/opt/deye_inverter_mqtt/deye_daemon.py", line 89, in do_task
regs |= self.modbus.read_registers(reg_range.first_reg_address, reg_range.last_reg_address)
File "/opt/deye_inverter_mqtt/deye_modbus.py", line 50, in read_registers
modbus_resp_frame = self.connector.send_request(modbus_frame + modbus_crc)
File "/opt/deye_inverter_mqtt/deye_at_connector.py", line 95, in send_request
if at_response.startswith(b'+ok='):
AttributeError: 'NoneType' object has no attribute 'startswith'
2023-09-09 15:46:08,475 - paho.mqtt.client - DEBUG - Sending PINGREQ
2023-09-09 15:46:08,477 - paho.mqtt.client - DEBUG - Received PINGRESP
2023-09-09 15:46:10,272 - DeyeDaemon - INFO - Reading start
2023-09-09 15:46:10,273 - DeyeDaemon - INFO - Reading registers [metrics group: micro, range: 003c-0074]
2023-09-09 15:46:10,273 - DeyeAtConnector - DEBUG - Sending AT command: b'WIFIKIT-214028-READ'
2023-09-09 15:46:10,863 - DeyeAtConnector - DEBUG - Received response frame in 1. attempt: b'<IP_ADDRESS>,E8FDF88E20F6,4196253664'
2023-09-09 15:46:10,863 - DeyeAtConnector - DEBUG - Sending AT command: b'+ok'
2023-09-09 15:46:11,364 - DeyeAtConnector - DEBUG - Sending AT command: b'AT+INVDATA=8,0103003c003945d4\n'
2023-09-09 15:46:11,938 - DeyeAtConnector - DEBUG - Received response frame in 1. attempt: b'+ok=01\x1003\x1072\x1000\x101D\x1000\x1000\x1000\x1000\x100F\x10F2\x1000\x1000\x1000\x100E\x1000\x100E\x1000\x1000\x1000\x1000\x1007\x10BD\x1000\x1000\x1007\x10D1\x1000\x1000\x1009\x1024\x1000\x1000\x1000\x1000\x1000\x1001\x1000\x1000\x1000\x1000\x1013\x1088\x1000\x1000\x1000\x1000\x1000\x1000\x1000\x1000\x1000\x1000\x1000\x1000\x1001\x1068\x1000\x1000\x1000\x1000\x1000\x1000\x1012\x1098\x1000\x1000\x1000\x1000\x1000\x1000\x1000\x1000\x1000\x1000\x1000\x1000\x1000\x1000\x1000\x1000\x1000\x1000\x1000\x1000\x1000\x1000\x1000\x1000\x1000\x1000\x1000\x1000\x1000\x1000\x1000\x1000\x1000\x1000\x1000\x1000\x1000\x10F6\x1000\x1007\x1000\x10F8\x1000\x1007\x1000\x1000\x1000\x1000\x1000\x1000\x1000\x1000\x10BB\x10AA\x10\r\n\r\n'
2023-09-09 15:46:11,938 - DeyeAtConnector - DEBUG - Extracted Modbus response 010372001D000000000FF20000000E000E0000000007BD000007D1000009240000000000010000000013880000000000000000000000000168000000000000129800000000000000000000000000000000000000000000000000000000000000000000000000F6000700F800070000000000000000
2023-09-09 15:46:11,939 - DeyeAtConnector - DEBUG - Sending AT command: b'AT+Q\n'
2023-09-09 15:46:12,440 - DeyeModbus - ERROR - Modbus frame is too short
2023-09-09 15:46:12,443 - DeyeMqttClient - DEBUG - Publishing message. topic: 'deye/logger_status', value: 'offline'
2023-09-09 15:46:12,443 - paho.mqtt.client - DEBUG - Sending PUBLISH (d0, q1, r0, m4), 'b'deye/logger_status'', ... (7 bytes)
2023-09-09 15:46:12,445 - paho.mqtt.client - DEBUG - Received PUBACK (Mid: 4)
2023-09-09 15:46:12,445 - DeyeMqttClient - INFO - Logger is offline
2023-09-09 15:46:12,445 - DeyeDaemon - INFO - Reading completed

With the tool from @maehtricks  works
inverter v0.13.0
(Set log level 0: ERROR)
InverterInfo(ip='<IP_ADDRESS>', mac='E8FDF88E20F6', serial=4196253664)
Fetch...PV1 Voltage,PV2 Voltage,PV1 Current,PV2 Current,Daily Production,Daily Production 1,Daily Production 2,Total Production,Total Production 1,Total Production 2,Active Power Regulations,PV1 Power,PV2 Power,Total Power,
Signing off with "AT+Q"...Goodbye ;)
────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
Inverter Values
┏━━━━━━━━━┳━━━━━━━━━━━━━━━━━━━━━━━━━━┳━━━━━━━━━━━━━━━━━━┳━━━━━━━━━━┳━━━━━━━━┳━━━━━━━━━━━━┓
┃ Counter ┃                     Name ┃ Value            ┃ Register ┃ Length ┃   Raw data ┃
┡━━━━━━━━━╇━━━━━━━━━━━━━━━━━━━━━━━━━━╇━━━━━━━━━━━━━━━━━━╇━━━━━━━━━━╇━━━━━━━━╇━━━━━━━━━━━━┩
│       1 │              PV1 Voltage │         23.4 V   │   006D   │   1    │       00ea │
│       2 │              PV2 Voltage │         24.6 V   │   006F   │   1    │       00f6 │
│       3 │              PV1 Current │          0.4 A   │   006E   │   1    │       0004 │
│       4 │              PV2 Current │          0.4 A   │   0070   │   1    │       0004 │
│       5 │         Daily Production │          2.9 kWh │   003C   │   1    │       001d │
│       6 │       Daily Production 1 │          1.4 kWh │   0041   │   1    │       000e │
│       7 │       Daily Production 2 │          1.4 kWh │   0042   │   1    │       000e │
│       8 │         Total Production │        408.2 kWh │   003F   │   2    │   0ff20000 │
│       9 │       Total Production 1 │        198.1 kWh │   0045   │   1    │       07bd │
│      10 │       Total Production 2 │        200.1 kWh │   0047   │   1    │       07d1 │
│      11 │ Active Power Regulations │          100 %   │   0028   │   1    │       0064 │
│      12 │                PV1 Power │         9.36 W   │    -     │   -    │ (Computed) │
│      13 │                PV2 Power │         9.84 W   │    -     │   -    │ (Computed) │
│      14 │              Total Power │         19.2 W   │    -     │   -    │ (Computed) │
└─────────┴──────────────────────────┴──────────────────┴──────────┴────────┴────────────┘
───────────────────────────────────────────────────── Sa 09 Sep 2023 18:06:33  ─────────────────────────────────────────────────────

2023-09-09 16:27:13,632 - DeyeDaemon - INFO - Please help me build the list of compatible inverters. https://github.com/kbialek/deye-inverter-mqtt/issues/41 2023-09-09 16:27:13,666 - paho.mqtt.client - DEBUG - Sending CONNECT (u0, p0, wr1, wq1, wf1, c1, k60) client_id=b'deye-inverter-3939493096' 2023-09-09 16:27:13,668 - paho.mqtt.client - DEBUG - Received CONNACK (0, 0) 2023-09-09 16:27:14,669 - paho.mqtt.client - DEBUG - Sending PUBLISH (d0, q1, r1, m1), 'b'deye/status'', ... (6 bytes) 2023-09-09 16:27:14,670 - DeyeMqttClient - INFO - Successfully connected to MQTT Broker located at <IP_ADDRESS>:1883 2023-09-09 16:27:14,671 - DeyeDaemon - INFO - Feature "Report metrics over MQTT": enabled 2023-09-09 16:27:14,671 - DeyeDaemon - INFO - Feature "Set inverter time once online": disabled 2023-09-09 16:27:14,672 - DeyeDaemon - DEBUG - Start to execute the daemon at intervals of 30 seconds 2023-09-09 16:27:14,674 - paho.mqtt.client - DEBUG - Received PUBACK (Mid: 1) 2023-09-09 16:27:14,675 - DeyeDaemon - INFO - Reading start 2023-09-09 16:27:14,677 - DeyeDaemon - INFO - Reading registers [metrics group: micro, range: 003c-0074] 2023-09-09 16:27:14,681 - DeyeConnector - DEBUG - Request frame: a5170010450000e8e4cfea0200000000000000000000000000000103003c003945d48515 2023-09-09 16:27:14,686 - DeyeConnector - DEBUG - Received response frame in 1. attempt: 41542b595a434d505645523d4d57335f3136555f353430365f322e32370d0a0d0a 2023-09-09 16:27:14,687 - DeyeModbus - ERROR - Response frame has invalid starting byte 2023-09-09 16:27:14,688 - DeyeMqttClient - DEBUG - Publishing message. topic: 'deye/logger_status', value: 'offline' 2023-09-09 16:27:14,690 - paho.mqtt.client - DEBUG - Sending PUBLISH (d0, q1, r0, m2), 'b'deye/logger_status'', ... (26 bytes) 2023-09-09 16:27:14,692 - paho.mqtt.client - DEBUG - Received PUBACK (Mid: 2) 2023-09-09 16:27:14,694 - DeyeMqttClient - INFO - Logger is offline 2023-09-09 16:27:14,694 - DeyeDaemon - INFO - Reading completed

Thanks for the logs. They are very helpful. I see where the problem is. My logger appends trailing zeros to the Modbus response. You can see it here https://github.com/kbialek/deye-inverter-mqtt/issues/123#issuecomment-1712438301 I'm talking about this "+ok=01030204423AB50000"
In my initial implementation I've decided to blindly drop them. However your loggers work correctly and do not append those trailing zeros, so the "fix" I've added actually broke it.
Now it's also clear for me why https://github.com/jedie/inverter-connect does not work for me. Exactly because of these trailing zeros.
Here is a new, fixed docker image ghcr.io/kbialek/deye-inverter-mqtt:2023.09.1-beta-2

Thanks a lot.
I have deployed it but I can test it tomorrow, because the inverter is currently down without sun.
I will report then.

I would also like to say a big thank you for your quick work. Update has been installed, but we won't see the result until tomorrow morning. It's hard for me to stand on the carport roof with a headlight and illuminate the solar panel...
what should the neighbors think....
so let's hope for the best!

Many thanks from me too, but it seems still not working.
2023-09-10 05:58:19,374 - DeyeDaemon - INFO - Please help me  build the list of compatible inverters. https://github.com/ kbialek/deye-inverter-mqtt/issues/41 2023-09-10 05:58:19,408 - paho.mqtt.client - DEBUG - Sending  CONNECT (u0, p0, wr1, wq1, wf1, c1, k60) client_id=b'deye-i nverter-3939493096' 2023-09-10 05:58:19,410 - paho.mqtt.client - DEBUG - Receive d CONNACK (0, 0) 2023-09-10 05:58:20,412 - paho.mqtt.client - DEBUG - Sending  PUBLISH (d0, q1, r1, m1), 'b'deye/status'', ... (6 bytes) 2023-09-10 05:58:20,413 - DeyeMqttClient - INFO - Successful ly connected to MQTT Broker located at <IP_ADDRESS>:1883 2023-09-10 05:58:20,413 - DeyeDaemon - INFO - Feature "Repor t metrics over MQTT": enabled 2023-09-10 05:58:20,414 - DeyeDaemon - INFO - Feature "Set i nverter time once online": disabled 2023-09-10 05:58:20,414 - DeyeDaemon - DEBUG - Start to exec ute the daemon at intervals of 30 seconds 2023-09-10 05:58:20,416 - paho.mqtt.client - DEBUG - Receive d PUBACK (Mid: 1) 2023-09-10 05:58:20,417 - DeyeDaemon - INFO - Reading start 2023-09-10 05:58:20,419 - DeyeDaemon - INFO - Reading regist ers [metrics group: micro, range: 003c-0074] 2023-09-10 05:58:20,424 - DeyeConnector - DEBUG - Request fr ame: a5170010450000e8e4cfea020000000000000000000000000000010 3003c003945d48515 2023-09-10 05:58:20,429 - DeyeConnector - DEBUG - Received r esponse frame in 1. attempt: 41542b595a434d505645523d4d57335 f3136555f353430365f322e32370d0a0d0a 2023-09-10 05:58:20,430 - DeyeModbus - ERROR - Response fram e has invalid starting byte 2023-09-10 05:58:20,431 - DeyeMqttClient - DEBUG - Publishin g message. topic: 'deye/logger_status', value: 'offline' 2023-09-10 05:58:20,431 - paho.mqtt.client - DEBUG - Sending  PUBLISH (d0, q1, r0, m2), 'b'deye/logger_status'', ... (26 bytes) 2023-09-10 05:58:20,434 - paho.mqtt.client - DEBUG - Receive d PUBACK (Mid: 2) 2023-09-10 05:58:20,436 - DeyeMqttClient - INFO - Logger is offline 2023-09-10 05:58:20,436 - DeyeDaemon - INFO - Reading comple ted 2023-09-10 05:58:50,437 - DeyeDaemon - INFO - Reading start 2023-09-10 05:58:50,437 - DeyeDaemon - INFO - Reading regist ers [metrics group: micro, range: 003c-0074] 2023-09-10 05:58:50,442 - DeyeConnector - DEBUG - Request fr ame: a5170010450000e8e4cfea020000000000000000000000000000010 3003c003945d48515 2023-09-10 05:58:50,444 - DeyeConnector - DEBUG - Received r esponse frame in 1. attempt: 41542b595a434d505645523d4d57335 f3136555f353430365f322e32370d0a0d0a 2023-09-10 05:58:50,446 - DeyeModbus - ERROR - Response fram e has invalid starting byte 2023-09-10 05:58:50,447 - DeyeMqttClient - DEBUG - Publishin g message. topic: 'deye/logger_status', value: 'offline' 2023-09-10 05:58:50,448 - paho.mqtt.client - DEBUG - Sending  PUBLISH (d0, q1, r0, m3), 'b'deye/logger_status'', ... (26 bytes) 2023-09-10 05:58:50,450 - paho.mqtt.client - DEBUG - Receive d PUBACK (Mid: 3) 2023-09-10 05:58:50,452 - DeyeMqttClient - INFO - Logger is offline 2023-09-10 05:58:50,452 - DeyeDaemon - INFO - Reading comple ted
I have tested if I really deployed the patch but it looks good.
docker pull g hcr.io/kbialek/deye-inverter-mqtt:2023.09.1-beta-2 2023.09.1-beta-2: Pulling from kbialek/deye-inverter-mqtt Digest: sha256:71b42b946f63212d71684cbf86831ab285155dfbc37b7 b143c57f6a313bddc4b Status: Image is up to date for ghcr.io/kbialek/deye-inverte r-mqtt:2023.09.1-beta-2 ghcr.io/kbialek/deye-inverter-mqtt:2023.09.1-beta-2

@carstenfroehlich I'm affraid that you are running wrong image. There should be no log messages from DeyeConnector class, because it's not in use by the AT command integration.
2023-09-10 05:58:20,424 - DeyeConnector - DEBUG - Request fr ame: a5170010450000e8e4cfea020000000000000000000000000000010

@Joerglp @carstenfroehlich Here is a new docker image with another bugfix ghcr.io/kbialek/deye-inverter-mqtt:2023.09.1-beta-3

Maybe I am doing something absolutely wrong, but I have pulled the third patch and restarted my docker container.
Result is still the same and I have still the debug message from DeyeConnector Class...

@carstenfroehlich Pulling is not enough. This image is not tagged as latest, thus you also have to explicitly reference the image version in your docker run configuration.

@carstenfroehlich Pulling is not enough. This image is not tagged as latest, thus you also have to explicitly reference the image version in your docker run configuration.

OK, thanks, I have to read about this a bit. Until now I always checked out a branch, restart my container and it works. I have currently no idea where to find this docker run configuration. Do you mean the docker compose file?

@carstenfroehlich If you use docker-compose - then yes, you should reference the image like this
services:
  deye-mqtt:
    image: ghcr.io/kbialek/deye-inverter-mqtt:2023.09.1-beta-3
    env_file:
      - config.env
    restart: unless-stopped

Hello, thank.
It‘s work now.

Hi,
the patch is working, but it seems, that the output format for telegraf is not correct.
My influxdb is not receiving other data than the total_energy.
2023-09-10T08:46:53Z D! [outputs.influxdb_v2] Wrote batch of 10 metrics in 8.814369ms 2023-09-10T08:46:53Z D! [outputs.influxdb_v2] Buffer fullness: 0 / 10000 metrics mqtt_consumer,host=dfd91121bec7,topic=tele/tasmota_E27D60/SENSOR LK13BE_Power_curr=267<PHONE_NUMBER>678723268 mqtt_consumer,host=dfd91121bec7,topic=tele/tasmota_E27D60/SENSOR LK13BE_Power_curr=268<PHONE_NUMBER>685585777 mqtt_consumer,host=dfd91121bec7,topic=tele/tasmota_E27D60/SENSOR LK13BE_Power_curr=267<PHONE_NUMBER>686476802 mqtt_consumer,host=dfd91121bec7,topic=tele/tasmota_E27D60/SENSOR LK13BE_Power_curr=266<PHONE_NUMBER>709000591 mqtt_consumer,host=dfd91121bec7,topic=tele/tasmota_E27D60/SENSOR LK13BE_Power_curr=267<PHONE_NUMBER>642289198 mqtt_consumer,host=dfd91121bec7,topic=tele/tasmota_E27D60/SENSOR LK13BE_Power_curr=267<PHONE_NUMBER>697057763 mqtt_consumer,host=dfd91121bec7,topic=tele/tasmota_E27D60/SENSOR LK13BE_Power_curr=266<PHONE_NUMBER>649502380 mqtt_consumer,host=dfd91121bec7,topic=tele/tasmota_E27D60/SENSOR LK13BE_Power_curr=267<PHONE_NUMBER>654414048 mqtt_consumer,host=dfd91121bec7,topic=tele/tasmota_E27D60/SENSOR LK13BE_Power_curr=267<PHONE_NUMBER>656056068 mqtt_consumer,host=dfd91121bec7,topic=tele/tasmota_E27D60/SENSOR LK13BE_Power_curr=266<PHONE_NUMBER>657921937 2023-09-10T08:46:53Z D! [outputs.file] Wrote batch of 10 metrics in 1.887356ms 2023-09-10T08:46:53Z D! [outputs.file] Buffer fullness: 0 / 10000 metrics 2023-09-10T08:46:53Z E! [inputs.mqtt_consumer] Error in plugin: invalid character ':' after top-level value 2023-09-10T08:46:54Z E! [inputs.mqtt_consumer] Error in plugin: invalid character ':' after top-level value 2023-09-10T08:46:55Z E! [inputs.mqtt_consumer] Error in plugin: invalid character ':' after top-level value 2023-09-10T08:46:56Z E! [inputs.mqtt_consumer] Error in plugin: invalid character ':' after top-level value 2023-09-10T08:46:57Z E! [inputs.mqtt_consumer] Error in plugin: invalid character ':' after top-level value 2023-09-10T08:46:58Z E! [inputs.mqtt_consumer] Error in plugin: invalid character 'o' looking for beginning of value 2023-09-10T08:46:58Z E! [inputs.mqtt_consumer] Error in plugin: must be an object or an array of objects 2023-09-10T08:46:58Z E! [inputs.mqtt_consumer] Error in plugin: must be an object or an array of objects 2023-09-10T08:46:58Z E! [inputs.mqtt_consumer] Error in plugin: must be an object or an array of objects 2023-09-10T08:46:58Z E! [inputs.mqtt_consumer] Error in plugin: must be an object or an array of objects 2023-09-10T08:46:58Z E! [inputs.mqtt_consumer] Error in plugin: must be an object or an array of objects 2023-09-10T08:46:58Z E! [inputs.mqtt_consumer] Error in plugin: must be an object or an array of objects 2023-09-10T08:46:58Z E! [inputs.mqtt_consumer] Error in plugin: must be an object or an array of objects 2023-09-10T08:46:58Z E! [inputs.mqtt_consumer] Error in plugin: must be an object or an array of objects 2023-09-10T08:46:58Z E! [inputs.mqtt_consumer] Error in plugin: must be an object or an array of objects 2023-09-10T08:46:58Z E! [inputs.mqtt_consumer] Error in plugin: must be an object or an array of objects 2023-09-10T08:46:58Z E! [inputs.mqtt_consumer] Error in plugin: must be an object or an array of objects 2023-09-10T08:46:58Z E! [inputs.mqtt_consumer] Error in plugin: must be an object or an array of objects 2023-09-10T08:46:58Z E! [inputs.mqtt_consumer] Error in plugin: must be an object or an array of objects 2023-09-10T08:46:58Z E! [inputs.mqtt_consumer] Error in plugin: must be an object or an array of objects 2023-09-10T08:46:58Z E! [inputs.mqtt_consumer] Error in plugin: must be an object or an array of objects 2023-09-10T08:46:58Z E! [inputs.mqtt_consumer] Error in plugin: must be an object or an array of objects 2023-09-10T08:46:58Z E! [inputs.mqtt_consumer] Error in plugin: must be an object or an array of objects 2023-09-10T08:46:58Z E! [inputs.mqtt_consumer] Error in plugin: must be an object or an array of objects 2023-09-10T08:46:58Z E! [inputs.mqtt_consumer] Error in plugin: must be an object or an array of objects 2023-09-10T08:46:58Z E! [inputs.mqtt_consumer] Error in plugin: must be an object or an array of objects 2023-09-10T08:46:58Z E! [inputs.mqtt_consumer] Error in plugin: must be an object or an array of objects 2023-09-10T08:46:58Z E! [inputs.mqtt_consumer] Error in plugin: must be an object or an array of objects 2023-09-10T08:46:58Z E! [inputs.mqtt_consumer] Error in plugin: must be an object or an array of objects 2023-09-10T08:46:58Z E! [inputs.mqtt_consumer] Error in plugin: must be an object or an array of objects 2023-09-10T08:46:58Z E! [inputs.mqtt_consumer] Error in plugin: must be an object or an array of objects 2023-09-10T08:46:58Z E! [inputs.mqtt_consumer] Error in plugin: must be an object or an array of objects 2023-09-10T08:46:58Z E! [inputs.mqtt_consumer] Error in plugin: must be an object or an array of objects 2023-09-10T08:46:58Z E! [inputs.mqtt_consumer] Error in plugin: must be an object or an array of objects 2023-09-10T08:46:58Z E! [inputs.mqtt_consumer] Error in plugin: must be an object or an array of objects 2023-09-10T08:46:58Z E! [inputs.mqtt_consumer] Error in plugin: must be an object or an array of objects 2023-09-10T08:46:58Z E! [inputs.mqtt_consumer] Error in plugin: must be an object or an array of objects 2023-09-10T08:46:58Z E! [inputs.mqtt_consumer] Error in plugin: invalid character ':' after top-level value ^X2023-09-10T08:46:59Z E! [inputs.mqtt_consumer] Error in plugin: invalid character ':' after top-level value 2023-09-10T08:47:00Z E! [inputs.mqtt_consumer] Error in plugin: invalid character ':' after top-level value 2023-09-10T08:47:01Z E! [inputs.mqtt_consumer] Error in plugin: invalid character ':' after top-level value 2023-09-10T08:47:02Z E! [inputs.mqtt_consumer] Error in plugin: invalid character ':' after top-level value 2023-09-10T08:47:03Z D! [outputs.influxdb_v2] Wrote batch of 10 metrics in 8.820892ms 2023-09-10T08:47:03Z D! [outputs.influxdb_v2] Buffer fullness: 0 / 10000 metrics mqtt_consumer,host=dfd91121bec7,topic=tele/tasmota_E27D60/SENSOR LK13BE_Power_curr=267<PHONE_NUMBER>661503043 mqtt_consumer,host=dfd91121bec7,topic=tele/tasmota_E27D60/SENSOR LK13BE_Power_curr=281<PHONE_NUMBER>663369052 mqtt_consumer,host=dfd91121bec7,topic=tele/tasmota_E27D60/SENSOR LK13BE_Power_curr=280<PHONE_NUMBER>663010770 mqtt_consumer,host=dfd91121bec7,topic=tele/tasmota_E27D60/SENSOR LK13BE_Power_curr=280<PHONE_NUMBER>668391001 mqtt_consumer,host=dfd91121bec7,topic=tele/tasmota_E27D60/SENSOR LK13BE_Power_curr=282<PHONE_NUMBER>674698329 mqtt_consumer,host=dfd91121bec7,topic=tele/tasmota_E27D60/SENSOR LK13BE_Power_curr=282<PHONE_NUMBER>684564933 mqtt_consumer,host=dfd91121bec7,topic=tele/tasmota_E27D60/SENSOR LK13BE_Power_curr=282<PHONE_NUMBER>704615890 mqtt_consumer,host=dfd91121bec7,topic=tele/tasmota_E27D60/SENSOR LK13BE_Power_curr=282<PHONE_NUMBER>679162818 mqtt_consumer,host=dfd91121bec7,topic=tele/tasmota_E27D60/SENSOR LK13BE_Power_curr=282<PHONE_NUMBER>677448298 mqtt_consumer,host=dfd91121bec7,topic=tele/tasmota_E27D60/SENSOR LK13BE_Power_curr=282<PHONE_NUMBER>687034480 2023-09-10T08:47:03Z D! [outputs.file] Wrote batch of 10 metrics in 1.948691ms 2023-09-10T08:47:03Z D! [outputs.file] Buffer fullness: 0 / 10000 metrics 2023-09-10T08:47:03Z E! [inputs.mqtt_consumer] Error in plugin: invalid character ':' after top-level value 2023-09-10T08:47:04Z E! [inputs.mqtt_consumer] Error in plugin: invalid character ':' after top-level value

@carstenfroehlich

the patch is working, but it seems, that the output format for telegraf is not correct.
My influxdb is not receiving other data than the total_energy.

This is strange. My changes have nothing to do with metrics processing. Perhaps there was an unhandled communication error with the logger, which caused that. Please collect more logs.
@Joerglp
Nice. It's working for me too. Let's run it for one more day to see if it's stable enough.

Here is another docker image ghcr.io/kbialek/deye-inverter-mqtt:2023.09.1-beta-4
Before using it, you have to update your configuration

Remove DEYE_LOGGER_PORT env variable
Add DEYE_LOGGER_PROTOCOL=at env variable

For more info read this https://github.com/kbialek/deye-inverter-mqtt/tree/feature/at-interface#installation
@carstenfroehlich Please check if it also resolves your problem with influx integration.

sorry, but there seems to be an error in logging
docker logs deye-inverter-mqtt_deye-mqtt_1 Error setting up logging: int() argument must be a string, a bytes-like object or a real number, not 'NoneType' Error setting up logging: int() argument must be a string, a bytes-like object or a real number, not 'NoneType' Error setting up logging: int() argument must be a string, a bytes-like object or a real number, not 'NoneType' Error setting up logging: int() argument must be a string, a bytes-like object or a real number, not 'NoneType' Error setting up logging: int() argument must be a string, a bytes-like object or a real number, not 'NoneType' Error setting up logging: int() argument must be a string, a bytes-like object or a real number, not 'NoneType'

The problems in influx integration are not solved.
With the beta-4 image i do not get any data anymore...
When I reset to the master, logging is working again, but not receiving any data like before

The beta 4 image is working for me.  When this variable is not present the error you posted is printed. You see it once per minute, because docker restarts the container.

@kbialek
Beta3 is running flawlessly for me so far. Telegraf fetches the data from Mqtt and delivers it to the influxDB.
Thanks again!
I'll get back to you in a few days and let you know whether the beta is running smoothly.

@Joerglp Thanks. Could you please test beta-4 too? Instructions are here https://github.com/kbialek/deye-inverter-mqtt/issues/123#issuecomment-1712760875

@carstenfroehlich I'm pretty much confident that you are still running the latest or 2023.08.1 image version, which requires DEYE_LOGGER_PORT env variable. When this variable is not present the error you posted is printed. You see it once per minute, because docker restarts the container.
EDIT: Or one of the former beta version. Please simply ensure that you are running ghcr.io/kbialek/deye-inverter-mqtt:2023.09.1-beta-4

you are totally right, sorry for the confusion.
I had additionally to the image entry an build entry in my docker compose file, so it was always overwriting your beta image!
Thanks a lot for your support!
I will test it tomorrow, but currently this is the log:
2023-09-10 18:46:17,870 - DeyeDaemon - INFO - Please help me build the list of compatible inverters. https://github.com/kbialek/deye-inverter-mqtt/issues/41
2023-09-10 18:46:17,870 - DeyeConnectorFactory - INFO - Creating Modbus/AT Logger connector
2023-09-10 18:46:17,871 - DeyeAtConnector - INFO - Hello
2023-09-10 18:46:17,903 - paho.mqtt.client - DEBUG - Sending CONNECT (u0, p0, wr1, wq1, wf1, c1, k60) client_id=b'deye-inverter-3939493096'
2023-09-10 18:46:17,906 - paho.mqtt.client - DEBUG - Received CONNACK (0, 0)
2023-09-10 18:46:18,908 - paho.mqtt.client - DEBUG - Sending PUBLISH (d0, q1, r1, m1), 'b'deye/status'', ... (6 bytes)
2023-09-10 18:46:18,909 - DeyeMqttClient - INFO - Successfully connected to MQTT Broker located at <IP_ADDRESS>:1883
2023-09-10 18:46:18,909 - DeyeDaemon - INFO - Feature "Report metrics over MQTT": enabled
2023-09-10 18:46:18,910 - DeyeDaemon - INFO - Feature "Set inverter time once online": disabled
2023-09-10 18:46:18,910 - DeyeDaemon - DEBUG - Start to execute the daemon at intervals of 30 seconds
2023-09-10 18:46:18,911 - paho.mqtt.client - DEBUG - Received PUBACK (Mid: 1)
2023-09-10 18:46:18,912 - DeyeDaemon - INFO - Reading start
2023-09-10 18:46:18,913 - DeyeDaemon - INFO - Reading registers [metrics group: micro, range: 003c-0074]
2023-09-10 18:46:18,914 - DeyeAtConnector - DEBUG - Sending AT command: b'WIFIKIT-214028-READ'
2023-09-10 18:46:20,015 - DeyeAtConnector - DEBUG - Connection response timeout
2023-09-10 18:46:21,017 - DeyeAtConnector - DEBUG - Connection response timeout
2023-09-10 18:46:22,018 - DeyeAtConnector - DEBUG - Connection response timeout
2023-09-10 18:46:23,020 - DeyeAtConnector - DEBUG - Connection response timeout
2023-09-10 18:46:24,022 - DeyeAtConnector - DEBUG - Connection response timeout
2023-09-10 18:46:24,022 - DeyeAtConnector - WARNING - Too many connection timeouts
2023-09-10 18:46:24,023 - DeyeAtConnector - DEBUG - Sending AT command: b'+ok'
2023-09-10 18:46:24,124 - DeyeAtConnector - DEBUG - Sending AT command: b'AT+INVDATA=8,0103003c003945d4\n'
Looks good!

@kbialek  beta4 ist deployed.  I'll see if it's working during the day.

Now the inverter seems to be damaged... The external relay has worked for one day. Now the inverter shows a permanent red light. So poorly I'm out for testing...

Everything is still going great for me.

It's been working for me without crashes so far

Same for me. It seems like the implementation is good enough.

The latest beta before the release ghcr.io/kbialek/deye-inverter-mqtt:2023.09.1-beta-5

Ok! Is deployed. What was changed? Ich give answer tomorrow.

I've merged this https://github.com/kbialek/deye-inverter-mqtt/pull/125


Ignore spaces in authorized emails list

Got burned by this one: trailing spaces in the authorized e-mail list would cause a mismatch when a user attempted to log in. This PR trims any spaces from the file.

Good update!


JWE Support

Issue https://github.com/golang-jwt/jwt/issues/67
Add support of JWE with one key (Compact)
Add AES GCM cipher to encrypt content
Add RSA-OAEP to encrypt key
Add test from RFC7516 Section 3.3
cc @mfridman @oxisto

@oxisto if you have free time, review the PR, please

I would like to finish this PR by Tuesday(12.07) inclusive.
If your schedule allows it, I'm willing to fix comments ASAP.
CC @mfridman @oxisto

Hey there, thanks for putting a PR .. but additions/changes related to security take time to review. It requires brushing up on the JWE specification and ensuring the implementation matches that and there is no bugs or security issues to the best of our abilities.
Furthermore, a lot of folks submit PR's, but then it's the maintainers who are on the hook to support that code and address bugs, issues, improvements, subsequent PR's, etc.
I can't speak for others, but right now is the end of quarter crunch time .. so my availability for open-source projects is limited. Tbh, adding JWE support isn't very high on my list and I'd rather not rush something for the sake of getting something out there.

I have understood your position. Thank you for your response.

@oxisto Thank you for review. I fixed all comments

@oxisto Thank you for review. I fixed all comments

Thank you! I have one small last comment for the errors and then I would suggest merging this initial version. Everything else can be done in increments.

@oxisto Added your suggestion


Rework step theorem generation to be faster and cache intermediate results to the environment

Description:
Forewarning: the diff of this one is rather large.
I've implemented a new version of step theorem generation, culminating in the genStepEqTheorem function.
In particular:

We get rid of the different fetch/decode/exec intermediate lemma, instead opting to generate the final step theorem in one go. The bottleneck seems to be kernel checking, so by reducing the number of theorems sent to the kernel we achieve a good speedup (SHA512 used to take about 55 seconds for the three generation commands combined, now it's about 35 seconds).
In the process, we build a ProgramInfo struct, which holds a bunch of interesting expressions that further proof automation could exploit. This programInfo is stored in a persistent environment extension, so that it is persisted in the olean files (hence, making it available to downstream files).
While building the previous, I've moved some definitions around and did other refactors: happy to split those off into their own PR if that makes reviewing easier.

EDIT: split off #93 for the #time command
Testing:
make all succeeded
License:
By submitting this pull request, I confirm that my contribution is
made under the terms of the Apache 2.0 license.

@alexkeizer I'll give this PR another read on Mon, with a fresher brain and hopefully a broader outlook. This is so exciting!

For illustration, on the latest commit in main, the linux CI built the Proofs module in:
✔ [449/450] Built Proofs
Build completed successfully.
real 134.36
user 360.74
sys 16.15

Whereas, on the latest commit of this PR, it only took:
✔ [448/449] Built Proofs
Build completed successfully.
real 104.34
user 263.48
sys 15.58

@shigoel this is now ready to merge, but I unfortunately cannot hit that button myself


uSync breaks when Vendr uSync V2 installed

Working on Umbraco 9 with uSync 9.0.1 with clean fresh installs, tried to install Vendr uSync 2 and, uSync dashboard disappears console error is following;
{"ExceptionMessage":"The given key 'Vendr' was not present in the dictionary.","ExceptionType":"System.Collections.Generic.KeyNotFoundException, System.Private.CoreLib, Version=<IP_ADDRESS>, Culture=neutral, PublicKeyToken=7cec85d7bea7798e","StackTrace":"   at System.Collections.Generic.Dictionary`2.get_Item(TKey key)\r\n   at uSync.BackOffice.Controllers.uSyncDashboardApiController.<>c.<GetHandlerGroups>b__29_1(String v)\r\n   at System.Linq.Enumerable.ToDictionary[TSource,TKey,TElement](IEnumerable`1 source, Func`2 keySelector, Func`2 elementSelector, IEqualityComparer`1 comparer)\r\n   at System.Linq.Enumerable.ToDictionary[TSource,TKey,TElement](IEnumerable`1 source, Func`2 keySelector, Func`2 elementSelector)\r\n   at uSync.BackOffice.Controllers.uSyncDashboardApiController.GetHandlerGroups()\r\n   at lambda_method693(Closure , Object , Object[] )\r\n   at Microsoft.AspNetCore.Mvc.Infrastructure.ActionMethodExecutor.SyncObjectResultExecutor.Execute(IActionResultTypeMapper mapper, ObjectMethodExecutor executor, Object controller, Object[] arguments)\r\n   at Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker.InvokeActionMethodAsync()\r\n   at Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker.Next(State& next, Scope& scope, Object& state, Boolean& isCompleted)\r\n   at Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker.InvokeNextActionFilterAsync()\r\n--- End of stack trace from previous location ---\r\n   at Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker.Rethrow(ActionExecutedContextSealed context)\r\n   at Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker.Next(State& next, Scope& scope, Object& state, Boolean& isCompleted)\r\n   at Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker.InvokeInnerFilterAsync()\r\n--- End of stack trace from previous location ---\r\n   at Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker.<InvokeNextExceptionFilterAsync>g__Awaited|25_0(ResourceInvoker invoker, Task lastTask, State next, Scope scope, Object state, Boolean isCompleted)"}

Uninstalling Vendr uSync 2 fixes the uSync dashboard.

yep - its actually a uSync UI issue (looking for an icon it doesn't have a key for) - its fixed in uSync, we will push an update out soon (just checking a couple of other things too)
https://github.com/KevinJump/uSync/commit/614d34b9d36ae993f47494d77949a1abfe61176c


unresolved import gdk::Rectangle. There is no Rectangle in gdk

When I try to build it I get the following errors:
master/src/signal.rs:16:5: 16:14 error: unresolved import gdk::Rectangle. There is no Rectangle in gdk
/home/alex/.cargo/git/checkouts/gtk-38cf3f4d9926c12a/master/src/signal.rs:16     Rectangle, Screen,
^~~~~~~~~
master/src/signal.rs:105:27: 105:36 error: unresolved import gdk::Rectangle. There is no Rectangle in gdk
/master/src/signal.rs:105         EventWindowState, Rectangle, Screen,
^~~~~~~~~
error: aborting due to 2 previous errors
Could not compile gtk.

Looks like I just needed to update my gtk fork. If you run a cargo update and then build again it should work now.


[Bug] Is MediaElement supported on Xamarin.Forms.UWP?

Description
Is MediaElement supported on Xamarin.Forms.UWP?
I can't find any special setup required in the documentation for UWP and I can't get it working
(v1.0.2 in combination with XF <IP_ADDRESS>5)
The uwp version of the sample application also does not work for me.

Lets merge this one with #788

Lets merge this one with #788


Use DialTLSContextFunc instead of tls.Config for NewProxyAutoTLSTransport

Current NewProxyAutoTLSTransport takes TLSConfig. It is easy to use but impossible to customize to verify custom SAN.
So, this patch replaces it with DialTLSContext.
Alternative
I considered a downstream may be using NewProxyAutoTLSTransport with TLSConfig. But NewProxyAutoTLSTransport was added for internal encryption https://github.com/knative/pkg/pull/2479 1 year ago. If an user wants NewProxyAutoTLSTransport to take TLSConfig we can add it later.
See also https://github.com/knative/serving/pull/14452

/cc @dprotaso @KauzClay @davidhadas @ReToCode

So by switching to use the DialTLSContext, it will let us insert some custom logic to handle setting up the TLS connection, such as verifying a custom SAN?

Yes, that's right.

But just for my understanding, why is the GetCertificate function on the TLSConfig not enough for this case? My understanding was you could use that to get SAN info from the client hello, and in there you could return the correct cert. Perhaps I'm mixing things up?

We want the client to validate if the server certificate is correctly returned from the expected namespace or not - i.e. prevent MITM attacks.
"you could use that to get SAN info from the client hello, and in there you could return the correct cert." allows the server to return the correct SAN, yes, but the client does not validate even if the certificate is returned by an impostor.

We want the client to validate if the server certificate matches the certificate of the expected namespace - i.e., to prevent MITM attacks.
"you could use that to get SAN info from the client hello, and in there you could return the correct cert." allows the server to return a correct certificate, yes, but the client does not validate the SAN even if an impostor returns a certificate by using another namespace's certificate.

Okay I see, I was mixing up client and server activities. Thanks for taking the time to explain that, I appreciate it 👍
Seems like a good change to me, but perhaps you want Dave or Reto to see it as well?

I learned how to use these labels lol
It looks good to me, but I'll put it on hold. @nak3 feel free to unhold, or keep it held for Reto or someone else to look at.
/lgtm
/hold

@dprotaso Could you please take a look at this and https://github.com/knative/serving/pull/14452 ?
Then if you are alright, override Downstream Knative / Unit Test (knative/serving) ?

It might be simpler to plumb in a tls.Config with GetConfigForClient set?

GetConfigForClient is only available to verify client certificates on server side[1]. We want to verify server certificate so it seems not available here.
[1] https://pkg.go.dev/crypto/tls#Config

// GetConfigForClient, if not nil, is called after a ClientHello is
// received from a client.

/test unit-tests

/lgtm
/approve


PowerBI Taxonomy Query

I'm getting an error updating the PowerBI report.  The Taxonomy query is trying to pull data from Items:TaxonomyHiddenList.  It appears this table is empty and thus causes cascading errors for the rest of the queries.
Any idea of where a could look to resolve this issue?
Thanks in advance for your help.

Create temporary items in Events and Requests lists. It is important to use some term field which will populate item in TaxonomyHiddenList. Then try the data refresh in Power BI Desktop.


Fixed #35648 -- Extended SafeString to support radd.

Trac ticket number
ticket-35648
Branch description
SafeString.__add__ should return NotImplemented if it isn't sure it can handle the RHS so that the RHS gets a chance at running its __radd__ method.
Checklist

[x] This PR targets the main branch.
[ ] The commit message is written in past tense, mentions the ticket number, and ends with a period.
[x] I have checked the "Has patch" ticket flag in the Trac system.
[x] I have added or updated relevant tests.
[x] I have added or updated relevant docs, including release notes if applicable.
[ ] I have attached screenshots in both light and dark modes for any UI changes.

Thank you! I have added the changes to the tests and a release note.
I thought a bit about merging your test_add_str with https://github.com/django/django/blob/8cf931dd2fde2561a615b96d5f709c15b672c4ba/tests/utils_tests/test_safestring.py#L71-L78 but I don't it makes the test case clearer, so I left both of them as they are now.

Hi @nessita
Thanks for your comments! I have applied the requested change to the SafeString implementation.
I have also worked on the tests. The class Strange is again splitted into a selection of classes which all only ever override __add__ or __radd__ -- I think it's clearer what's going on because it's immediately obvious which of the methods is executed. That isn't the case when overriding both in the same class.
I have also added two subtests showing that the SafeData marker is preserved when safe strings are involved, and nothing else.
Thanks again!

Thank you! That was a great experience :)


Ruby on Rails:  Bare Metal Forms and Helpers project completed

A new application was created with one model (User) and its controller with new and create actions and a form to add records to the table. We have worked with three types of forms:

Plain HTML
Form_tag
Form_for

Also, validations were added, as also the style for the fields with errors.

Thanks for the feedback @Oluwadamilareolusakin . Your suggested corrections have been addressed.


New Logo Proposal

Hello,
It would be an honor for me to create a new logo design for your project, is there any chance I can contribute? Please do comment.
Thank You

Deb

hello, can I update this issue?


mobile: Revert "mobile: always enable using platform certificate validation"

Commit Message: Reverting https://github.com/envoyproxy/envoy/pull/26033 as platform cert validation breaks the upload of Envoy Mobile stats. The issue is being discussed offline.
Additional Description:
Risk Level: Low
Testing:
Docs Changes:
Release Notes:
Platform Specific Features:
[Optional Runtime guard:]
[Optional Fixes #Issue]
[Optional Fixes commit #PR or SHA]
[Optional Deprecated:]
[Optional API Considerations:]

@RyanTheOptimist @abeyad  Needed to add 1-line change to the revert to make the platform cert validation configurable for when we use new Swift interop engine builder (as opposed to Swift Engine builder -> obj-c EnvoyConfiguration). See 7c4abe0


nice work w/ hyperscript & observable

It's funny how if you used hyperscript and observables at the correct levels of abstraction, you could very easily build something like angular. And that doing it using these libraries would give you something server-side render-able, with no extra effort. Also, if you do it correctly, you don't re-render unnecessarily, and get the performance of something like react's dom-diffing, except without needing to do dom-diffing. Also, you will much better understand how your page interacts with other parts of the page (b/c the bindings are in code, in one place, not in the html and written into the angular library). ALSO, your validation functions get to be separate from your transformation functions (e.g. "".trim()), so you can reuse your validation on the server-side. ALSO ALSO you get designer-readable html depending on the level which you use hyperscript: if you are heavy on the selectors, then most of the html will already be in the page, rather than hidden in a template which needs the full server running into order to get the CSS to work against it.

I may have built something along the lines of what you're suggesting and I just found this thread out because I was migrating some of my Hyperscript code to Dominant (my library) but I forgot to convert one call to Dominant and Hyperscript just did "the right thing", namely call my function before setting the DOM property.
I had this: el('td', {class:'lt',innerHTML:function() {return l()[0]}}) (where el is Hyperscript).
But I meant this: d.el('td', {class:'lt',innerHTML:function() {return l()[0]}}) (where d.el is Dominant).
But on first render the DOM was updated as I had expected (meaning the innerHTML function was invoked and the return value was passed to the DOM) and I was "huh, I didn't know Hyperscript did this". Then I looked into the code and found something about "observables", which brought me to this thread.
Dominant doesn't use Dominic's observable library, but it does use functions much in the same way.
There are also no necessary redraws. Check the README if you're curious: https://github.com/guiprav/dominant


Bring back wTl from the dead...

...as bMlink, for reasons @varunagrawal enumerated.

Enumerated in #238


Database connection in server-less

I am using this example aws server-less environment.
I am able to deploy the code with given example on aws lambda. Now to use this in our actual project I need to use postgres and redis with swift.
I am unable to find example where i can use standalone postgresql  with server-side swift without using other server framework like Vapor.
Can you please help us in finding the right-way to integrate swift example with postgres and redis.
Thank you.

Hi @mihirpmehta,
I haven't tried to import Redis and Postgresql.
I suggest to try to import the libraries you find here: https://swift.org/server/
The requirement to integrate a library is:

Swift 5/5.1
If the library uses swift NIO, it's required to verify that swift NIO is 2.x

Thanks for your response.
I tried to integrate https://github.com/IBM-Swift/Swift-Kuery with given example but getting runtime error

/var/task/HelloWorld: error while loading shared libraries: libpq.so.5: cannot open shared object file: No such file or directory

Here is my docker file
FROM swift:5.1.1 as builder

RUN apt-get -qq update && apt-get -q -y install \
    libssl-dev libicu-dev

RUN DEBIAN_FRONTEND=noninteractive apt-get install -y libpq-dev

Will try to import libraries from https://swift.org/server/ and give it a try
Thanks

@mihirpmehta
If you add a library to the code, you need to copy them or in the Layer or with the Lambda.
Look at the structure of the Docker folder, there is a text file called swift-shared-library.txt that contains all the libraries you need to add to your layer.
I suggest creating your version of that file with the library you need. Once you add the library don't forget to upload the layer on AWS.

Thank you for your guidance. I am able to run the lambda with third party library now. Just one more query that i cannot resolve is, Can i run/test it in my local machine on terminal ? I am using Visual Code and Mac
Thanks

It's possible to run the test by using make test_package . But you need to add your unit test in swift. You should be able test the lambda. Look also to the packages to have some idea on how to do it.
You can run the test using visual studio code and the docker. The project has the configuration to support it. Look here on how to setup the environment: https://github.com/ianpartridge/vscode-remote-try-swift

Thanks. Will give it a try :)

Redis:
Here an example on how to use Redis with Swift Sprinter
Package.swift
import PackageDescription

let package = Package(
    name: "RedisDemo",
    dependencies: [
        // Dependencies declare other packages that this package depends on.
        // .package(url: /* package url */, from: "1.0.0"),
        .package(url: "https://github.com/swift-sprinter/aws-lambda-swift-sprinter-nio-plugin", from: "1.0.0-alpha.3"),
        .package(url: "https://gitlab.com/mordil/swift-redi-stack.git", from: "1.0.0-alpha.5"),
        .package(url: "https://github.com/apple/swift-log.git", from: "1.0.0"),
    ],
    targets: [
        // Targets are the basic building blocks of a package. A starget can define a module or a test suite.
        // Targets can depend on other targets in this package, and on products in packages which this package depends on.
        .target(
            name: "RedisDemo",
            dependencies: ["LambdaSwiftSprinterNioPlugin", "Logging", "RediStack"]),
        .testTarget(
            name: "RedisDemoTests",
            dependencies: ["RedisDemo"]),
    ]
)

Main.swift
import AsyncHTTPClient
import Foundation
#if canImport(FoundationNetworking)
import FoundationNetworking
#endif
import LambdaSwiftSprinter
import LambdaSwiftSprinterNioPlugin
import Logging
import NIO
import NIOFoundationCompat
import RediStack

struct Event: Codable {
    let key: String
    let value: String
}

struct Response: Codable {
    let value: String
}

enum LambdaError: Error {
    case redisConnectionFailed
}

let logger = Logger(label: "AWS.Lambda.Redis")
let elasticacheConfigEndpoint = "<your cluster>.euw1.cache.amazonaws.com"

let eventLoop = httpClient.eventLoopGroup.next()
let connection = try? RedisConnection.connect(
        to: try .makeAddressResolvingHost(elasticacheConfigEndpoint,
                                          port: RedisConnection.defaultPort),
        on: eventLoop
    ).wait()

let syncCodableNIOLambda: SyncCodableNIOLambda<Event, Response> = { (event, context) throws -> EventLoopFuture<Response> in

    guard let connection = connection else {
        throw LambdaError.redisConnectionFailed
    }

    let future = connection.set(event.key, to: event.value)
        .flatMap {
            return connection.get(event.key)
        }
        .map { content -> Response in
            return Response(value: content ?? "")
        }
    return future
}

do {

    let sprinter = try SprinterNIO()
    //Note amend this line in case if it's required to use a different lambda handler.
    sprinter.register(handler: "setGet", lambda: syncCodableNIOLambda)

    try sprinter.run()
} catch {
    logger.error("\(String(describing: error))")
}

Note
I used Redis with AWS Elastic Cache
Requirements:

The lambda must be attached to the VPC configured for Elastic Cache
Fix the user role mus have the policy AWSLambdaVPCAccessExecutionRole

The full example is here: https://github.com/Andrea-Scuderi/aws-lambda-swift-sprinter/tree/feature/Redis

Redis:
Here an example on how to use PostgreSQL with Swift Sprinter:
Package.swift
import PackageDescription

let package = Package(
    name: "PostgreSQLDemo",
    dependencies: [
        // Dependencies declare other packages that this package depends on.
        // .package(url: /* package url */, from: "1.0.0"),
         .package(url: "https://github.com/swift-sprinter/aws-lambda-swift-sprinter-nio-plugin", from: "1.0.0-alpha.3"),
        .package(url: "https://github.com/vapor/postgres-nio.git", from: "1.0.0-alpha.1.6"),
        .package(url: "https://github.com/apple/swift-log.git", from: "1.0.0"),
    ],
    targets: [
        // Targets are the basic building blocks of a package. A target can define a module or a test suite.
        // Targets can depend on other targets in this package, and on products in packages which this package depends on.
        .target(
            name: "PostgreSQLDemo",
            dependencies: ["LambdaSwiftSprinterNioPlugin", "Logging", "PostgresNIO"]),
        .testTarget(
            name: "PostgreSQLDemoTests",
            dependencies: ["PostgreSQLDemo"]),
    ]
)

main.swift
import AsyncHTTPClient
import Foundation
#if canImport(FoundationNetworking)
import FoundationNetworking
#endif
import LambdaSwiftSprinter
import LambdaSwiftSprinterNioPlugin
import Logging
import NIO
import NIOFoundationCompat
import PostgresNIO

struct Event: Codable {
    let query: String
}

struct Response: Codable {
    let value: String
}

enum LambdaError: Error {
    case connectionFailed
}

let logger = Logger(label: "AWS.Lambda.Redis")
let endpoint = "<yourdb>.rds.amazonaws.com"
do {
    let eventLoop = httpClient.eventLoopGroup.next()
    let connection = try PostgresConnection.connect(
        to: try .makeAddressResolvingHost(endpoint,
                                          port: 5432),
        on: eventLoop
    ).wait()

    logger.error("after connection")

    try connection.authenticate(username: "<username>",
                                database: "<db>",
                                password: "<password>").wait()

    let syncCodableNIOLambda: SyncCodableNIOLambda<Event, Response> = { (event, context) throws -> EventLoopFuture<Response> in

        let future = connection.query(event.query).map { (rows) -> Response in
            return Response(value: "\(rows)")

        }
        return future
    }

    let sprinter = try SprinterNIO()
    //Note amend this line in case if it's required to use a different lambda handler.
    sprinter.register(handler: "query", lambda: syncCodableNIOLambda)

    try sprinter.run()
} catch {
    logger.error("\(String(describing: error))")
}

Note
I used Redis with AWS RDS
Requirements:
The lambda must be attached to the VPC configured for Elastic Cache

Fix the user role must have the policy AWSLambdaVPCAccessExecutionRole
The Lambda must have a policy to allow connection to RDS
The full example is here:

https://github.com/Andrea-Scuderi/aws-lambda-swift-sprinter/tree/feature/PostgreSQLDemo

This is great help indeed. Thanks


SPM: swift test does not work

This is most likely due to using Quick as the testing framework. Quick specs via SPM is experimental and requires a different approach than the normal spm test route introduced in #885.

Thank you for opening this up @scottrhoyt, this was an oversight on my part when setting up Package.swift.
I'll try to take a shot at it next week, but I'm open to someone else running with it as well 💯

No worries, @AndrewSB. I figured we might have some issues with SPM + Quick, but that was no reason to not at least support SPM installs. We just might want to sort it out before we try to be SPM-first. The current workaround for Quick isn't pretty and doesn't work with spm test either.


Implement Rotations when in "Move Components" mode

After a component is selected, it should have a small circle in the right hand corner that can be used to rotate it. This will require emitting and applying a new type of edit event that rotates
/bounty $25

@seveibar how do you imagine the button to look like? you hold and spin it around the component to rotate it?

Can I get assigned this issue please ?

/attempt #92

Can I be assigned? @seveibar

@Bhavyajain21 @UTK-a-RSH we don't assign bounties except for time consuming ones

@Bhavyajain21 @UTK-a-RSH we don't assign bounties except for time consuming ones

Do we have a discord channel for tscircuit?

@Bhavyajain21 https://discord.gg/RvyP4V9Q


Plugin not loading ?

hello so i put the plugin in the directory :

and when i go to plugin menu :

i have nothing :

what i doing wrong ?
thanks

Did you restart KeePass? If KeePass can't load a plugin you will see a message box.

yes  i m using keeepass 1
now with keepas 2
works


Enable strict mode toggle in storybook

Closes
✅ Pull Request Checklist:

[ ] Included link to corresponding React Spectrum GitHub Issue.
[ ] Added/updated unit tests and storybook for this change (for new code or code which already has tests).
[ ] Filled out test instructions.
[ ] Updated documentation (if it already exists for this component).
[ ] Looked at the Accessibility Practices for this feature - Aria Practices

📝 Test Instructions:
Test locally, toggle strict mode in storybook via the toolbar at the top. Check that stories with overlays break when strict mode is enabled
🧢 Your Project:
RSP

Reopening due to provider breaking in stories upon save (components using useProvider will complain that scale isn't defined anymore). This issue seems to happen on main already but only intermittently, adding the strict mode decorator seems to make it happen a lot more though

Note that saving changes in certain files (FocusScope) may cause the storybook to lag a bit, most likely due to some fast refresh shenanigans. At least it doesn't crash anymore though, final fix will be done in Parcel


i18n(es): updates dev-toolbar-app-reference

Description (required)
Updates dev-toolbar-app-reference based on this commit 71de23ab285806bcd3cd0d3b88889fcb7ee2892d

Related issues & labels (optional)

Closes # N/A
Suggested label: i18n

Lunaria Status Overview
🌕 This pull request will trigger status changes.

Learn more
By default, every PR changing files present in the Lunaria configuration's files property will be considered and trigger status changes accordingly.
You can change this by adding one of the keywords present in the ignoreKeywords property in your Lunaria configuration file in the PR's title (ignoring all files) or by including a tracker directive in the merged commit's description.

Tracked Files

Locale
File
Note

es
reference/dev-toolbar-app-reference.mdx
Localization changed, will be marked as complete.

Warnings reference

Icon
Description

🔄
The source for this localization has been updated since the creation of this pull request, make sure all changes in the source have been applied.


Test TCK compliance

There is a branch https://github.com/unitsofmeasurement/unit-tck-usage/tree/seshat for testing Seshat against the TCK.

@desruisseaux Did SIS pass the 1.0.1 TCK earlier? Please feel free to adopt the TCK usage demo where necessary. I found it tricky because all implementing classes for Unit etc. seem hidden behind package-private visibility, so hard to say, how the TCK may be configured to find those for basic tests e.g. in section 4.1?

I have run the TCK on Apache SIS a while ago. Indeed, implementation classes are package-privated (not designed for being extended). If the issue is about providing a tec.units.tck.util.ServiceConfiguration, the usual approach is to provide such implementation in the same package than the package-private classes to be tested.

Ported TestConfiguration and META-INF/services/tec.units.tck.util.ServiceConfiguration from unit-tck-usage seshat branch to the main Seshat project and tried to add unit-tck as a Maven test dependency, but it cause the following error message at build time:
[TestNG] [ERROR] No test suite found. Nothing to run
Usage: <main class> [options] The XML suite files to run
  Options:
    -configfailurepolicy
       Configuration failure policy (skip or continue)
    ...etc...

How are we suppose to use the TCK in a Maven build?

It's all set up in the tck-usage repository.
Please feel free to make the necessary adjustments, e.g. matching package in the https://github.com/unitsofmeasurement/unit-tck-usage/tree/seshat branch. As soon as something is pushed to any branch, the build starts. This is the TestNG report for the EDR stage of Indriya: https://104-41443578-gh.circle-artifacts.com/0/home/circleci/repo/target/tck-output/index.html Implementations are free to test it locally, but this way full transparence of a compatibility claim is possible, something e.g. Jakarta EE hopes to find ways how this could also be done in a similar way at Eclipse.org.

If it worked better to deploy Snapshot builds of Seshat at the Geo

After #6 was done and snapshots get deployed, the seshat branch of unit-tck-usage runs through. However, there are still 2 failures: https://117-41443578-gh.circle-artifacts.com/0/home/circleci/repo/target/tck-output/tck-results.txt Seshat does not contain a concrete Quantity implementation, so even if you pass just Quantity as such to the test configuration, the interface is missing hashCode() and equals().

I added a test case for Quantity.equals(Object) and hashCode() implementations and verified that those methods work as intended. The TCK test which is failing checks for explicit equals and hashCode methods in implementation. But Seshat implementation is, in some case, a java.lang.reflect.Proxy class which does not declare explicitly those methods. But it inherits them from java.lang.Object and I verified that they are invoked as expected.
Proposed fixes:
We can declare the equals and hashCode methods in the Quantity interface. This is a compatible change since an implementation of those methods is inherited from java.lang.Object, so no code will be broken. I think it is desirable because if the TCK is testing those methods, it means that we expect some contract to be met. We are better to document this contract explicitly in Javadoc.
The TCK TestUtils.testHasPublicMethod method currently gets the list of methods by a call to Class.getDeclaredMethods(), filter the public methods, then search in super-classes (source code). I think we should just invoke Class.getMethods() instead, which will perform all those steps for us (no need anymore for the loop). I'm not sure why the current code does not see the equals and hashCode methods in Proxy case, but my hope is that the use of getMethods() would work around this issue.

I guess we could do that, but it would require an API change. Whether that's a trival tiny change we're able to declare "2.0.1" and release on the fly or it needs a MR, I'll ask @otaviojava and the PMO as they are all at OC1 right now. It seems we did win a JCP Award for the JSR last night. Stay tuned for that on the orga page later this week.

The proposed change in Quantity interface is low priority and can be delayed until there is more material for an eventual later version. For the proposed changes in the TCK, we would need to test if it solve the issue.

Is there a PR for the TCK? And if so, which branches of the TCK does it make sense for? If Seshat intends to implement JSR 385 in the near future, then maybe stick to master/2.0, if it stays with 1.0 for some time, then we could also do something there. Please if there is a PR file it in the appropriate branch(es)

Patch is not yet created. My problem is that I do not know how to test it? Do you have a link to a documentation about how to execute the TCK from command-line?

It is both in https://github.com/unitsofmeasurement/unit-tck, but you may want to run it via https://github.com/unitsofmeasurement/unit-tck-usage. There is a RunTCK class, but you may want to use Maven like in the https://github.com/unitsofmeasurement/unit-tck-usage/tree/seshat branch. Because Seshat has many package-local classes, the TestConfiguration had to be refactored to its own package, but that seems perfectly fine. If e.g. the README in the TCK Usage project was too short or you find something could be added, please provide a PR there as well if you can.

I also try to look at the Seshat GH-page branch later today.

TCK tests have been integrated to the build and are executed at every mvn clean install invocation. One issue is that the clean phase is currently mandatory. To avoid this limitation, I did not yet found anyway other than bypassing ServiceLoader for the particular case of ServiceConfiguration (it is still fine to use ServiceLoader for ServiceProvider).

What is the problem with the clean phase? And is this specific fo Seshat being tested or specific to the TCK? I am not aware it would be mandatory but it is a good thing go run because not everywhere the Docker container or similar VM is recreated every time.

The build failure is generic to any implementation compiled as Jigsaw module, unless I missed some Jigsaw configuration that would allow to avoid it.
The relationship with the clean phase is specific to Seashat. It is because Seashat creates a multi-versions JAR files in this order:

Compile for Java 8.
Test.
Compile for Java 9 as Jigsaw module.

So the Jigsaw modularisation happen before the tests. But if the clean phase as not been executed, then the Java 9 classes are present at test time and cause the failure.
The problem with Jigsaw is that I have not found anyway to declare a service (in this case ServiceConfiguration) at test time only, without declaring that service in the main code. Putting a file in src/test/resources/META-INF/services works for non-Jigsaw module but not with Jigsaw. But maybe some way exists and I just didn't found it.


Add gamepad support to PLATFORM_DESKTOP_SDL

Adds gamepad support to PLATFORM_DESKTOP_SDL.
Tested on FreeBSD 13

@The-Night-Watch Looks great! Thank you very much! 😄


See build 1300.9: https://travis-ci.org/boostorg/compute/builds/115231140.
This PR fixes those erros and add OSX Travis-CI build without running tests (because currently a few tests fail on OSX) in order to avoid such a mistakes in the future. (OSX build with tests is still allowed to fail.) There is also a small code refactoring in strided_iterator.hpp  .

Coverage decreased (-0.0%)

lol

Looks good! Thanks!

That's weird about coveralls...


Lack of web_app_data in message

Expected behavior
Message class contains webAppData field
Actual behavior
Message class doesn't contain webAppData field
To Reproduce
Create a web app and try to send data back to the bot via sendData js method

Implemented on #272