Nearly working - commands not reaching controller

Hi - thanks for the amazing project, I wonder if you would mind advising me on where to go from here please?
I have a Lolin D32 esp board with LIN transciever and buck regulator as usual but most importantly, this exact hardware works with the derived project https://github.com/FujiHeatPump/esphome-fujitsu.  All i did to try out the native homekit solution from this project is re-flash it, I didn't change any connections.
I want to try native Homekit now, so with your fine project, all I changed is in the Arduino IDE the board of course, and the serial port pins for my already built hardware:
#define RX_PIN 16 (RXD2)
#define TX_PIN 17 (TXD2)
NOTE I do not have a neopixel connected in case that's important.
I can pair the unit in homekit (actually took a few attempts, probably not related), but get no control or status, continually get "no response". HVAC continues to work fine on the wall panel/remote, no errors or anything.
Would you mind looking at the logs below and any advice on how to troubleshoot?
Maybe it is to do with "UNSUPPORTED MODE IN convertACModeToHKMode 0! RETURNING 0" ?
I have triple checked that my LIN chip RX pin is connected to GPIO16 and TX to GPIO17 as it seems everything works but it's not communicating to the Fujitsu remote. Could the pins be updated elsewhere or do the logs tell you something different is the issue....?
I believe that the lines "update(): coolingThresholdTemperature -> using midpoint 21C instead" show the commands i am trying to give from Home app are getting to the device, but it's not communicating to the HVAC. I could be on totally the wrong path though :-)
Everything has been power cycled many times. The esp board is powered via regulator from the remote's 12V line.
It must be something simple, it's the same schematic as shown on your pages, with only a difference in serial port pins.

Device Name:      Fujitsu AirConditioner

Init FujitsuHK
UNSUPPORTED MODE IN convertACModeToHKMode 0! RETURNING 0
Finished setup

*** HomeSpan Info ***

‚û§ Accessory:  AID=1
   ‚ûü Service AccessoryInformation:  IID=1, UUID="3E"
      ‚á® Characteristic Name("Fujitsu AirConditioner D92DE6B4"):  IID=2, UUID="23", Perms=PR
      ‚á® Characteristic Manufacturer("Fujitsu"):  IID=3, UUID="20", Perms=PR
      ‚á® Characteristic SerialNumber("D92DE6B4"):  IID=4, UUID="30", Perms=PR
      ‚á® Characteristic Model("Fuji-HK"):  IID=5, UUID="21", Perms=PR
      ‚á® Characteristic FirmwareRevision("0.2"):  IID=6, UUID="52", Perms=PR+EV
      ‚á® Characteristic Identify(0):  IID=7, UUID="14", Perms=PW
   ‚ûü Service HAPProtocolInformation:  IID=8, UUID="A2"
      ‚á® Characteristic Version("1.1.0"):  IID=9, UUID="37", Perms=PR
   ‚ûü Service HeaterCooler:  IID=10, UUID="BC"
      ‚á® Characteristic Active(0):  IID=11, UUID="B0", Perms=PR+PW+EV, Range=[0,1]
      ‚á® Characteristic CurrentTemperature(22):  IID=12, UUID="11", Perms=PR+EV, Custom-Range=[0,100,1]
      ‚á® Characteristic CurrentHeaterCoolerState(1):  IID=13, UUID="B1", Perms=PR+EV, Range=[0,3]
      ‚á® Characteristic TargetHeaterCoolerState(0):  IID=14, UUID="B2", Perms=PR+PW+EV, Range=[0,2]
      ‚á® Characteristic CoolingThresholdTemperature(22):  IID=15, UUID="D", Perms=PR+PW+EV, Custom-Range=[16,30,1]
      ‚á® Characteristic HeatingThresholdTemperature(22):  IID=16, UUID="12", Perms=PR+PW+EV, Custom-Range=[16,30,1]
      ‚á® Characteristic TemperatureDisplayUnits(0):  IID=17, UUID="36", Perms=PR+PW+EV, Range=[0,1]
      ‚á® Characteristic RotationSpeed(0):  IID=18, UUID="29", Perms=PR+PW+EV, Custom-Range=[0,100,25]

Configured as Bridge: NO

Database Validation:  Warnings=0, Errors=0

Service                             UUID         AID  IID  Update  Loop  Button  Linked Services
------------------------------  --------  ----------  ---  ------  ----  ------  ---------------
AccessoryInformation                  3E           1    1      NO    NO      NO  -
HAPProtocolInformation                A2           1    8      NO    NO      NO  -
HeaterCooler                          BC           1   10     YES   YES      NO  -

*** End Info ***

Accessory ID:      2D:7C:8E:A7:D2:FC                               LTPK: C9106E26D8C85B31CDCF90A15CDC234B43F6DF94D8CE311A35A58B016BBA5003
Paired Controller: F4BA6794-981A-4376-AA83-D5C147D682C5   (admin)  LTPK: C2A77EADD77E931167D8F34AB11B42EB2C0A9C903D7CF68F63CCABE473BCB132
Paired Controller: 2209C4CB-7D36-4F16-B417-DCC52BB52790 (regular)  LTPK: E94239F1B2A434D57E7500495814A7191C38D6B57C7934CB7EE956E4153CED35
Paired Controller: 130873E1-C06E-4075-AAA0-DD5F777785D5 (regular)  LTPK: CBD9AFDB816E44B72963E7FF039EB9813E3AC09EBDB3B18EBE9F40E6DA7F42FF

Accessory configuration number: 1

Fujitsu AirConditioner is READY!

Trying to connect to MYWIFI.  Waiting 1 sec...
WiFi Connected!  IP Address = <IP_ADDRESS>

Starting MDNS...

HostName:      FUJIAC-2D7C8EA7D2FC.local:80
Display Name:  Fujitsu AirConditioner
Model Name:    FUJIAC
Setup ID:      FUJI

Starting HAP Server on port 80 supporting 14 simultaneous HomeKit Controller Connections...

update(): coolingThresholdTemperature -> using midpoint 21C instead
update(): coolingThresholdTemperature -> using midpoint 21C instead
update(): coolingThresholdTemperature -> using midpoint 20C instead
update(): coolingThresholdTemperature -> using midpoint 20C instead

************************************************************
Welcome to HomeSpan!
Apple HomeKit for the Espressif ESP-32 WROOM and Arduino IDE
************************************************************

** Please ensure serial monitor is set to transmit <newlines>

Message Logs:     Level 0
Status LED:       Pin 27  (Auto Off=30 sec)
Device Control:   Pin 39
Sketch Version:   n/a
HomeSpan Version: 1.8.0
Arduino-ESP Ver.: 2.0.11
ESP-IDF Version:  4.4.5
ESP32 Chip:       ESP32-D0WD Rev 1 dual-core 4MB Flash
ESP32 Board:      d32
PWM Resources:    16 channels, 8 timers, max 20-bit duty resolution
Sodium Version:   1.0.12-idf  Lib 9.4
MbedTLS Version:  mbed TLS 2.28.3
Sketch Compiled:  Nov  8 2023 20:05:52
Partition:        app0
MAC Address:      B4:E6:2D:D9:71:05

Device Name:      Fujitsu AirConditioner

Init FujitsuHK
UNSUPPORTED MODE IN convertACModeToHKMode 0! RETURNING 0
Finished setup

*** HomeSpan Info ***

‚û§ Accessory:  AID=1
   ‚ûü Service AccessoryInformation:  IID=1, UUID="3E"
      ‚á® Characteristic Name("Fujitsu AirConditioner D92DE6B4"):  IID=2, UUID="23", Perms=PR
      ‚á® Characteristic Manufacturer("Fujitsu"):  IID=3, UUID="20", Perms=PR
      ‚á® Characteristic SerialNumber("D92DE6B4"):  IID=4, UUID="30", Perms=PR
      ‚á® Characteristic Model("Fuji-HK"):  IID=5, UUID="21", Perms=PR
      ‚á® Characteristic FirmwareRevision("0.2"):  IID=6, UUID="52", Perms=PR+EV
      ‚á® Characteristic Identify(0):  IID=7, UUID="14", Perms=PW
   ‚ûü Service HAPProtocolInformation:  IID=8, UUID="A2"
      ‚á® Characteristic Version("1.1.0"):  IID=9, UUID="37", Perms=PR
   ‚ûü Service HeaterCooler:  IID=10, UUID="BC"
      ‚á® Characteristic Active(0):  IID=11, UUID="B0", Perms=PR+PW+EV, Range=[0,1]
      ‚á® Characteristic CurrentTemperature(22):  IID=12, UUID="11", Perms=PR+EV, Custom-Range=[0,100,1]
      ‚á® Characteristic CurrentHeaterCoolerState(1):  IID=13, UUID="B1", Perms=PR+EV, Range=[0,3]
      ‚á® Characteristic TargetHeaterCoolerState(0):  IID=14, UUID="B2", Perms=PR+PW+EV, Range=[0,2]
      ‚á® Characteristic CoolingThresholdTemperature(22):  IID=15, UUID="D", Perms=PR+PW+EV, Custom-Range=[16,30,1]
      ‚á® Characteristic HeatingThresholdTemperature(22):  IID=16, UUID="12", Perms=PR+PW+EV, Custom-Range=[16,30,1]
      ‚á® Characteristic TemperatureDisplayUnits(0):  IID=17, UUID="36", Perms=PR+PW+EV, Range=[0,1]
      ‚á® Characteristic RotationSpeed(0):  IID=18, UUID="29", Perms=PR+PW+EV, Custom-Range=[0,100,25]

Configured as Bridge: NO

Database Validation:  Warnings=0, Errors=0

Service                             UUID         AID  IID  Update  Loop  Button  Linked Services
------------------------------  --------  ----------  ---  ------  ----  ------  ---------------
AccessoryInformation                  3E           1    1      NO    NO      NO  -
HAPProtocolInformation                A2           1    8      NO    NO      NO  -
HeaterCooler                          BC           1   10     YES   YES      NO  -

*** End Info ***

Accessory ID:      2D:7C:8E:A7:D2:FC                               LTPK: C9106E26D8C85B31CDCF90A15CDC234B43F6DF94D8CE311A35A58B016BBA5003
Paired Controller: F4BA6794-981A-4376-AA83-D5C147D682C5   (admin)  LTPK: C2A77EADD77E931167D8F34AB11B42EB2C0A9C903D7CF68F63CCABE473BCB132
Paired Controller: 2209C4CB-7D36-4F16-B417-DCC52BB52790 (regular)  LTPK: E94239F1B2A434D57E7500495814A7191C38D6B57C7934CB7EE956E4153CED35
Paired Controller: 130873E1-C06E-4075-AAA0-DD5F777785D5 (regular)  LTPK: CBD9AFDB816E44B72963E7FF039EB9813E3AC09EBDB3B18EBE9F40E6DA7F42FF

Accessory configuration number: 1

Fujitsu AirConditioner is READY!

Trying to connect to MYWIFI.  Waiting 1 sec...
WiFi Connected!  IP Address = <IP_ADDRESS>

Starting MDNS...

HostName:      FUJIAC-2D7C8EA7D2FC.local:80
Display Name:  Fujitsu AirConditioner
Model Name:    FUJIAC
Setup ID:      FUJI

Starting HAP Server on port 80 supporting 14 simultaneous HomeKit Controller Connections...

*** Log Level set to 2

=======================================
** Client #0 Connected: (12 sec) <IP_ADDRESS> on Socket 2/16

<<<<<<<<< <IP_ADDRESS> <<<<<<<<<
POST /pair-verify HTTP/1.1
Host: Fujitsu\032AirConditioner._hap._tcp.local
Content-Length: 37
Content-Type: application/pairing+tlv8
------------ END BODY! ------------
STATE(1) 01
PUBKEY(32) F97ED861FD0CA3A3B6648C2A403BA923FCB86F58868467F500BA382B605E8C12
------------ END TLVS! ------------
In Pair Verify #0 (<IP_ADDRESS>)...Found <M1>
------- ENCRYPTING SUB-TLVS -------
SIGNATURE(64) C35CF588A06050CBA588312283E39E46BF06CE75D4A2C8FB40B1F172ECDE6CBEEF173092DD45B36B64EA662AF266A661E27EEA205A14E3F12F9B2458989C1C01
IDENTIFIER(17) 32443A37433A38453A41373A44323A4643
---------- END SUB-TLVS! ----------

>>>>>>>>>> <IP_ADDRESS> >>>>>>>>>>
HTTP/1.1 200 OK
Content-Type: application/pairing+tlv8
Content-Length: 140

STATE(1) 02
PUBKEY(32) C1EDBA9530B3E3F1A658177D24EDDFABE633404F5997FE6AEFFE67F2D73FCF55
ENC.DATA(101) C511B8D29713AAF126EB2761F089D31E8320B4C503E12E72FC916AB62E8DC41367E535B651BC5348A23C40B732699D2AC04C27C2B2078BBDF666759759FDDA7CCFFF1445E06F9ADEC030EB4E5BF97630547D3C84BBF35674C321350EDA8AC8E869A0FB9AF6
------------ SENT! --------------

<<<<<<<<< <IP_ADDRESS> <<<<<<<<<
POST /pair-verify HTTP/1.1
Host: Fujitsu\032AirConditioner._hap._tcp.local
Content-Length: 125
Content-Type: application/pairing+tlv8
------------ END BODY! ------------
STATE(1) 03
ENC.DATA(120) B5880393DB13C6A07A194362FCAC7F17DBC479961A50E0CC2398E1F847A18EB9EE43C59F52A9CCF7E20737ADFDB1E08D3BA060DB0029D2F5687FCE99325691457BC8B04E76F9752481367D93B671F70910F8D65E96E6C858AC9329A5C1C6EAF01284FB4CBF24B2F051677F56E78188A466152ADE5A67321E
------------ END TLVS! ------------
In Pair Verify #0 (<IP_ADDRESS>)...Found <M3>
SIGNATURE(64) 9D463EC9F47141519D06DA50EBF83EFC9827F3EAD901CAF5DEA72DEB0BDA6B9DD21CCDFE027190D7509BEE770D342131EF67EDDC94C5BDC5F371793329DC9F02
IDENTIFIER(36)<PHONE_NUMBER>3739342D393831412D343337362D414138332D443543313437443638324335
------- END DECRYPTED TLVS! -------

>>>>>>>>>> <IP_ADDRESS> >>>>>>>>>>
HTTP/1.1 200 OK
Content-Type: application/pairing+tlv8
Content-Length: 3

STATE(1) 04
------------ SENT! --------------

*** SESSION VERIFICATION COMPLETE ***

A good start would be to add hp.debugPrint = true; just after the hp object connects: https://github.com/unreality/FujiHK/blob/3856c17ebb1a7e9938d94b8faac02dd32d44f5cd/src/fuji-hk.cpp#L410
It should print out the frames it sees on the bus. If you dont see any coming in, then your rx/tx lines might be mixed up, or the LIN controller not working correctly...

Thank you, I am trying that now:
<-- 0 A0 0 38 14 A0 3 20 mSrc: 0 mDst: 32 mType: 0 write: 0 login: 1 unknown: 1 onOff: 0 temp: 20, mode: 4 cP:1 uM:10 cTemp:1 acError:0
<-- 20 A1 0 38 14 80 2D 0 mSrc: 32 mDst: 33 mType: 0 write: 0 login: 1 unknown: 1 onOff: 0 temp: 20, mode: 4 cP:1 uM:8 cTemp:22 acError:0
--> 21 81 0 38 14 0 2D 0 mSrc: 33 mDst: 1 mType: 0 write: 0 login: 0 unknown: 1 onOff: 0 temp: 20, mode: 4 cP:1 uM:0 cTemp:22 acError:0
<-- 0 A0 0 38 14 A0 3 20 mSrc: 0 mDst: 32 mType: 0 write: 0 login: 1 unknown: 1 onOff: 0 temp: 20, mode: 4 cP:1 uM:10 cTemp:1 acError:0
<-- 20 A1 0 38 14 80 2D 0 mSrc: 32 mDst: 33 mType: 0 write: 0 login: 1 unknown: 1 onOff: 0 temp: 20, mode: 4 cP:1 uM:8 cTemp:22 acError:0
--> 21 81 0 38 14 0 2D 0 mSrc: 33 mDst: 1 mType: 0 write: 0 login: 0 unknown: 1 onOff: 0 temp: 20, mode: 4 cP:1 uM:0 cTemp:22 acError:0
<-- 0 A0 0 38 14 A0 3 20 mSrc: 0 mDst: 32 mType: 0 write: 0 login: 1 unknown: 1 onOff: 0 temp: 20, mode: 4 cP:1 uM:10 cTemp:1 acError:0
<-- 20 A1 0 38 14 80 2D 0 mSrc: 32 mDst: 33 mType: 0 write: 0 login: 1 unknown: 1 onOff: 0 temp: 20, mode: 4 cP:1 uM:8 cTemp:22 acError:0
--> 21 81 0 38 14 0 2D 0 mSrc: 33 mDst: 1 mType: 0 write: 0 login: 0 unknown: 1 onOff: 0 temp: 20, mode: 4 cP:1 uM:0 cTemp:22 acError:0
<-- 0 A0 0 38 14 A0 3 20 mSrc: 0 mDst: 32 mType: 0 write: 0 login: 1 unknown: 1 onOff: 0 temp: 20, mode: 4 cP:1 uM:10 cTemp:1 acError:0
<-- 20 A1 0 38 14 80 2D 0 mSrc: 32 mDst: 33 mType: 0 write: 0 login: 1 unknown: 1 onOff: 0 temp: 20, mode: 4 cP:1 uM:8 cTemp:22 acError:0
--> 21 81 0 38 14 0 2D 0 mSrc: 33 mDst: 1 mType: 0 write: 0 login: 0 unknown: 1 onOff: 0 temp: 20, mode: 4 cP:1 uM:0 cTemp:22 acError:0
<-- 0 A0 0 38 14 A0 3 20 mSrc: 0 mDst: 32 mType: 0 write: 0 login: 1 unknown: 1 onOff: 0 temp: 20, mode: 4 cP:1 uM:10 cTemp:1 acError:0
<-- 20 A1 0 38 14 80 2C 0 mSrc: 32 mDst: 33 mType: 0 write: 0 login: 1 unknown: 1 onOff: 0 temp: 20, mode: 4 cP:0 uM:8 cTemp:22 acError:0
--> 21 81 0 38 14 20 2D 0 mSrc: 33 mDst: 1 mType: 0 write: 0 login: 0 unknown: 1 onOff: 0 temp: 20, mode: 4 cP:1 uM:2 cTemp:22 acError:0
<-- 0 A0 0 38 14 A0 3 20 mSrc: 0 mDst: 32 mType: 0 write: 0 login: 1 unknown: 1 onOff: 0 temp: 20, mode: 4 cP:1 uM:10 cTemp:1 acError:0
<-- 20 A1 0 38 14 80 2C 0 mSrc: 32 mDst: 33 mType: 0 write: 0 login: 1 unknown: 1 onOff: 0 temp: 20, mode: 4 cP:0 uM:8 cTemp:22 acError:0
--> 21 81 0 38 14 20 2D 0 mSrc: 33 mDst: 1 mType: 0 write: 0 login: 0 unknown: 1 onOff: 0 temp: 20, mode: 4 cP:1 uM:2 cTemp:22 acError:0
<-- 0 A0 0 38 14 A0 3 20 mSrc: 0 mDst: 32 mType: 0 write: 0 login: 1 unknown: 1 onOff: 0 temp: 20, mode: 4 cP:1 uM:10 cTemp:1 acError:0
<-- 20 A1 0 38 14 80 2D 0 mSrc: 32 mDst: 33 mType: 0 write: 0 login: 1 unknown: 1 onOff: 0 temp: 20, mode: 4 cP:1 uM:8 cTemp:22 acError:0
--> 21 81 0 38 14 0 2D 0 mSrc: 33 mDst: 1 mType: 0 write: 0 login: 0 unknown: 1 onOff: 0 temp: 20, mode: 4 cP:1 uM:0 cTemp:22 acError:0
<-- 0 A0 0 38 14 A0 3 20 mSrc: 0 mDst: 32 mType: 0 write: 0 login: 1 unknown: 1 onOff: 0 temp: 20, mode: 4 cP:1 uM:10 cTemp:1 acError:0
<-- 20 A1 0 38 14 80 2D 0 mSrc: 32 mDst: 33 mType: 0 write: 0 login: 1 unknown: 1 onOff: 0 temp: 20, mode: 4 cP:1 uM:8 cTemp:22 acError:0
--> 21 81 0 38 14 0 2D 0 mSrc: 33 mDst: 1 mType: 0 write: 0 login: 0 unknown: 1 onOff: 0 temp: 20, mode: 4 cP:1 uM:0 cTemp:22 acError:0
<-- 0 A0 0 38 14 A0 3 20 mSrc: 0 mDst: 32 mType: 0 write: 0 login: 1 unknown: 1 onOff: 0 temp: 20, mode: 4 cP:1 uM:10 cTemp:1 acError:0
<-- 20 A1 0 38 14 80 2D 0 mSrc: 32 mDst: 33 mType: 0 write: 0 login: 1 unknown: 1 onOff: 0 temp: 20, mode: 4 cP:1 uM:8 cTemp:22 acError:0
--> 21 81 0 38 14 0 2D 0 mSrc: 33 mDst: 1 mType: 0 write: 0 login: 0 unknown: 1 onOff: 0 temp: 20, mode: 4 cP:1 uM:0 cTemp:22 acError:0

OK some more - the debug info above corresponds and updates with my actions on the remote control panel - here i turned it on, changed the temp to 30 - and it seesm to be commuicating. Very cool!
So comms seems to be OK - but please note it still takes many atempts and a long time to add the accessory to Home.  This is probably more of a pointer to the problem now....
<-- 20 A1 0 38 14 80 2D 0 mSrc: 32 mDst: 33 mType: 0 write: 0 login: 1 unknown: 1 onOff: 0 temp: 20, mode: 4 cP:1 uM:8 cTemp:22 acError:0
--> 21 81 0 38 14 0 2D 0 mSrc: 33 mDst: 1 mType: 0 write: 0 login: 0 unknown: 1 onOff: 0 temp: 20, mode: 4 cP:1 uM:0 cTemp:22 acError:0
<-- 0 A0 0 38 14 A0 3 20 mSrc: 0 mDst: 32 mType: 0 write: 0 login: 1 unknown: 1 onOff: 0 temp: 20, mode: 4 cP:1 uM:10 cTemp:1 acError:0
<-- 20 A1 0 38 14 80 2D 0 mSrc: 32 mDst: 33 mType: 0 write: 0 login: 1 unknown: 1 onOff: 0 temp: 20, mode: 4 cP:1 uM:8 cTemp:22 acError:0
--> 21 81 0 38 14 0 2D 0 mSrc: 33 mDst: 1 mType: 0 write: 0 login: 0 unknown: 1 onOff: 0 temp: 20, mode: 4 cP:1 uM:0 cTemp:22 acError:0
<-- 0 A0 0 38 14 A0 3 20 mSrc: 0 mDst: 32 mType: 0 write: 0 login: 1 unknown: 1 onOff: 0 temp: 20, mode: 4 cP:1 uM:10 cTemp:1 acError:0
<-- 20 A1 0 38 14 80 2D 0 mSrc: 32 mDst: 33 mType: 0 write: 0 login: 1 unknown: 1 onOff: 0 temp: 20, mode: 4 cP:1 uM:8 cTemp:22 acError:0
--> 21 81 0 38 14 0 2D 0 mSrc: 33 mDst: 1 mType: 0 write: 0 login: 0 unknown: 1 onOff: 0 temp: 20, mode: 4 cP:1 uM:0 cTemp:22 acError:0
<-- 0 A0 0 38 14 A0 3 20 mSrc: 0 mDst: 32 mType: 0 write: 0 login: 1 unknown: 1 onOff: 0 temp: 20, mode: 4 cP:1 uM:10 cTemp:1 acError:0
<-- 20 A1 0 38 14 80 2D 0 mSrc: 32 mDst: 33 mType: 0 write: 0 login: 1 unknown: 1 onOff: 0 temp: 20, mode: 4 cP:1 uM:8 cTemp:22 acError:0
--> 21 81 0 38 14 0 2D 0 mSrc: 33 mDst: 1 mType: 0 write: 0 login: 0 unknown: 1 onOff: 0 temp: 20, mode: 4 cP:1 uM:0 cTemp:22 acError:0
<-- 0 A0 0 38 14 A0 3 20 mSrc: 0 mDst: 32 mType: 0 write: 0 login: 1 unknown: 1 onOff: 0 temp: 20, mode: 4 cP:1 uM:10 cTemp:1 acError:0
<-- 20 A1 0 38 14 80 2D 0 mSrc: 32 mDst: 33 mType: 0 write: 0 login: 1 unknown: 1 onOff: 0 temp: 20, mode: 4 cP:1 uM:8 cTemp:22 acError:0
--> 21 81 0 38 14 0 2D 0 mSrc: 33 mDst: 1 mType: 0 write: 0 login: 0 unknown: 1 onOff: 0 temp: 20, mode: 4 cP:1 uM:0 cTemp:22 acError:0
<-- 0 A0 0 38 14 A0 3 20 mSrc: 0 mDst: 32 mType: 0 write: 0 login: 1 unknown: 1 onOff: 0 temp: 20, mode: 4 cP:1 uM:10 cTemp:1 acError:0
<-- 20 A1 0 38 14 80 2D 0 mSrc: 32 mDst: 33 mType: 0 write: 0 login: 1 unknown: 1 onOff: 0 temp: 20, mode: 4 cP:1 uM:8 cTemp:22 acError:0
--> 21 81 0 38 14 0 2D 0 mSrc: 33 mDst: 1 mType: 0 write: 0 login: 0 unknown: 1 onOff: 0 temp: 20, mode: 4 cP:1 uM:0 cTemp:22 acError:0
<-- 0 A0 0 38 14 A0 3 20 mSrc: 0 mDst: 32 mType: 0 write: 0 login: 1 unknown: 1 onOff: 0 temp: 20, mode: 4 cP:1 uM:10 cTemp:1 acError:0
<-- 20 A1 0 38 14 80 2E 0 mSrc: 32 mDst: 33 mType: 0 write: 0 login: 1 unknown: 1 onOff: 0 temp: 20, mode: 4 cP:0 uM:8 cTemp:23 acError:0
--> 21 81 0 38 14 20 2F 0 mSrc: 33 mDst: 1 mType: 0 write: 0 login: 0 unknown: 1 onOff: 0 temp: 20, mode: 4 cP:1 uM:2 cTemp:23 acError:0
<-- 0 A0 0 38 14 A0 3 20 mSrc: 0 mDst: 32 mType: 0 write: 0 login: 1 unknown: 1 onOff: 0 temp: 20, mode: 4 cP:1 uM:10 cTemp:1 acError:0
<-- 20 A1 0 38 14 80 2D 0 mSrc: 32 mDst: 33 mType: 0 write: 0 login: 1 unknown: 1 onOff: 0 temp: 20, mode: 4 cP:1 uM:8 cTemp:22 acError:0
--> 21 81 0 38 14 0 2D 0 mSrc: 33 mDst: 1 mType: 0 write: 0 login: 0 unknown: 1 onOff: 0 temp: 20, mode: 4 cP:1 uM:0 cTemp:22 acError:0
<-- 0 A0 0 38 14 A0 3 20 mSrc: 0 mDst: 32 mType: 0 write: 0 login: 1 unknown: 1 onOff: 0 temp: 20, mode: 4 cP:1 uM:10 cTemp:1 acError:0
<-- 20 A1 8 39 14 80 2D 0 mSrc: 32 mDst: 33 mType: 0 write: 1 login: 1 unknown: 1 onOff: 1 temp: 20, mode: 4 cP:1 uM:8 cTemp:22 acError:0
--> 21 81 0 39 14 0 2D 0 mSrc: 33 mDst: 1 mType: 0 write: 0 login: 0 unknown: 1 onOff: 1 temp: 20, mode: 4 cP:1 uM:0 cTemp:22 acError:0
<-- 0 A0 0 39 14 0 3 20 mSrc: 0 mDst: 32 mType: 0 write: 0 login: 1 unknown: 1 onOff: 1 temp: 20, mode: 4 cP:1 uM:0 cTemp:1 acError:0
<-- 20 A1 0 39 14 80 2D 0 mSrc: 32 mDst: 33 mType: 0 write: 0 login: 1 unknown: 1 onOff: 1 temp: 20, mode: 4 cP:1 uM:8 cTemp:22 acError:0
--> 21 81 0 39 14 0 2D 0 mSrc: 33 mDst: 1 mType: 0 write: 0 login: 0 unknown: 1 onOff: 1 temp: 20, mode: 4 cP:1 uM:0 cTemp:22 acError:0
<-- 0 A0 0 39 14 A0 3 20 mSrc: 0 mDst: 32 mType: 0 write: 0 login: 1 unknown: 1 onOff: 1 temp: 20, mode: 4 cP:1 uM:10 cTemp:1 acError:0
<-- 20 A1 0 39 14 80 2D 0 mSrc: 32 mDst: 33 mType: 0 write: 0 login: 1 unknown: 1 onOff: 1 temp: 20, mode: 4 cP:1 uM:8 cTemp:22 acError:0
--> 21 81 0 39 14 0 2D 0 mSrc: 33 mDst: 1 mType: 0 write: 0 login: 0 unknown: 1 onOff: 1 temp: 20, mode: 4 cP:1 uM:0 cTemp:22 acError:0
<-- 0 A0 0 39 14 A0 3 20 mSrc: 0 mDst: 32 mType: 0 write: 0 login: 1 unknown: 1 onOff: 1 temp: 20, mode: 4 cP:1 uM:10 cTemp:1 acError:0
<-- 20 A1 0 39 14 80 2D 0 mSrc: 32 mDst: 33 mType: 0 write: 0 login: 1 unknown: 1 onOff: 1 temp: 20, mode: 4 cP:1 uM:8 cTemp:22 acError:0
--> 21 81 0 39 14 0 2D 0 mSrc: 33 mDst: 1 mType: 0 write: 0 login: 0 unknown: 1 onOff: 1 temp: 20, mode: 4 cP:1 uM:0 cTemp:22 acError:0
<-- 0 A0 0 39 14 A0 3 20 mSrc: 0 mDst: 32 mType: 0 write: 0 login: 1 unknown: 1 onOff: 1 temp: 20, mode: 4 cP:1 uM:10 cTemp:1 acError:0
<-- 20 A1 0 39 14 80 2D 0 mSrc: 32 mDst: 33 mType: 0 write: 0 login: 1 unknown: 1 onOff: 1 temp: 20, mode: 4 cP:1 uM:8 cTemp:22 acError:0
--> 21 81 0 39 14 0 2D 0 mSrc: 33 mDst: 1 mType: 0 write: 0 login: 0 unknown: 1 onOff: 1 temp: 20, mode: 4 cP:1 uM:0 cTemp:22 acError:0
<-- 0 A0 0 39 14 A0 3 20 mSrc: 0 mDst: 32 mType: 0 write: 0 login: 1 unknown: 1 onOff: 1 temp: 20, mode: 4 cP:1 uM:10 cTemp:1 acError:0
<-- 20 A1 0 39 14 80 2D 0 mSrc: 32 mDst: 33 mType: 0 write: 0 login: 1 unknown: 1 onOff: 1 temp: 20, mode: 4 cP:1 uM:8 cTemp:22 acError:0
--> 21 81 0 39 14 0 2D 0 mSrc: 33 mDst: 1 mType: 0 write: 0 login: 0 unknown: 1 onOff: 1 temp: 20, mode: 4 cP:1 uM:0 cTemp:22 acError:0
<-- 0 A0 0 39 14 A0 3 20 mSrc: 0 mDst: 32 mType: 0 write: 0 login: 1 unknown: 1 onOff: 1 temp: 20, mode: 4 cP:1 uM:10 cTemp:1 acError:0
<-- 20 A1 0 39 14 80 2E 0 mSrc: 32 mDst: 33 mType: 0 write: 0 login: 1 unknown: 1 onOff: 1 temp: 20, mode: 4 cP:0 uM:8 cTemp:23 acError:0
--> 21 81 0 39 14 20 2F 0 mSrc: 33 mDst: 1 mType: 0 write: 0 login: 0 unknown: 1 onOff: 1 temp: 20, mode: 4 cP:1 uM:2 cTemp:23 acError:0
<-- 0 A0 0 39 14 A0 3 20 mSrc: 0 mDst: 32 mType: 0 write: 0 login: 1 unknown: 1 onOff: 1 temp: 20, mode: 4 cP:1 uM:10 cTemp:1 acError:0
<-- 20 A1 0 39 14 80 2E 0 mSrc: 32 mDst: 33 mType: 0 write: 0 login: 1 unknown: 1 onOff: 1 temp: 20, mode: 4 cP:0 uM:8 cTemp:23 acError:0
--> 21 81 0 39 14 20 2F 0 mSrc: 33 mDst: 1 mType: 0 write: 0 login: 0 unknown: 1 onOff: 1 temp: 20, mode: 4 cP:1 uM:2 cTemp:23 acError:0
<-- 0 A0 0 39 14 A0 3 20 mSrc: 0 mDst: 32 mType: 0 write: 0 login: 1 unknown: 1 onOff: 1 temp: 20, mode: 4 cP:1 uM:10 cTemp:1 acError:0
<-- 20 A1 0 39 14 80 2D 0 mSrc: 32 mDst: 33 mType: 0 write: 0 login: 1 unknown: 1 onOff: 1 temp: 20, mode: 4 cP:1 uM:8 cTemp:22 acError:0
--> 21 81 0 39 14 0 2D 0 mSrc: 33 mDst: 1 mType: 0 write: 0 login: 0 unknown: 1 onOff: 1 temp: 20, mode: 4 cP:1 uM:0 cTemp:22 acError:0
<-- 0 A0 0 39 14 A0 3 20 mSrc: 0 mDst: 32 mType: 0 write: 0 login: 1 unknown: 1 onOff: 1 temp: 20, mode: 4 cP:1 uM:10 cTemp:1 acError:0
<-- 20 A1 0 39 14 80 2D 0 mSrc: 32 mDst: 33 mType: 0 write: 0 login: 1 unknown: 1 onOff: 1 temp: 20, mode: 4 cP:1 uM:8 cTemp:22 acError:0
--> 21 81 0 39 14 0 2D 0 mSrc: 33 mDst: 1 mType: 0 write: 0 login: 0 unknown: 1 onOff: 1 temp: 20, mode: 4 cP:1 uM:0 cTemp:22 acError:0
<-- 0 A0 0 39 14 A0 3 20 mSrc: 0 mDst: 32 mType: 0 write: 0 login: 1 unknown: 1 onOff: 1 temp: 20, mode: 4 cP:1 uM:10 cTemp:1 acError:0
<-- 20 A1 0 39 14 80 2D 0 mSrc: 32 mDst: 33 mType: 0 write: 0 login: 1 unknown: 1 onOff: 1 temp: 20, mode: 4 cP:1 uM:8 cTemp:22 acError:0
--> 21 81 0 39 14 0 2D 0 mSrc: 33 mDst: 1 mType: 0 write: 0 login: 0 unknown: 1 onOff: 1 temp: 20, mode: 4 cP:1 uM:0 cTemp:22 acError:0
<-- 0 A0 0 39 14 A0 3 20 mSrc: 0 mDst: 32 mType: 0 write: 0 login: 1 unknown: 1 onOff: 1 temp: 20, mode: 4 cP:1 uM:10 cTemp:1 acError:0
<-- 20 A1 0 39 14 80 2D 0 mSrc: 32 mDst: 33 mType: 0 write: 0 login: 1 unknown: 1 onOff: 1 temp: 20, mode: 4 cP:1 uM:8 cTemp:22 acError:0
--> 21 81 0 39 14 0 2D 0 mSrc: 33 mDst: 1 mType: 0 write: 0 login: 0 unknown: 1 onOff: 1 temp: 20, mode: 4 cP:1 uM:0 cTemp:22 acError:0
<-- 0 A0 0 39 14 A0 3 20 mSrc: 0 mDst: 32 mType: 0 write: 0 login: 1 unknown: 1 onOff: 1 temp: 20, mode: 4 cP:1 uM:10 cTemp:1 acError:0
<-- 20 A1 0 39 14 80 2D 0 mSrc: 32 mDst: 33 mType: 0 write: 0 login: 1 unknown: 1 onOff: 1 temp: 20, mode: 4 cP:1 uM:8 cTemp:22 acError:0
--> 21 81 0 39 14 0 2D 0 mSrc: 33 mDst: 1 mType: 0 write: 0 login: 0 unknown: 1 onOff: 1 temp: 20, mode: 4 cP:1 uM:0 cTemp:22 acError:0
<-- 0 A0 0 39 14 A0 3 20 mSrc: 0 mDst: 32 mType: 0 write: 0 login: 1 unknown: 1 onOff: 1 temp: 20, mode: 4 cP:1 uM:10 cTemp:1 acError:0
<-- 20 A1 8 39 1E 80 2D 0 mSrc: 32 mDst: 33 mType: 0 write: 1 login: 1 unknown: 1 onOff: 1 temp: 30, mode: 4 cP:1 uM:8 cTemp:22 acError:0
--> 21 81 0 39 1E 0 2D 0 mSrc: 33 mDst: 1 mType: 0 write: 0 login: 0 unknown: 1 onOff: 1 temp: 30, mode: 4 cP:1 uM:0 cTemp:22 acError:0
<-- 0 A0 0 39 1E 0 3 20 mSrc: 0 mDst: 32 mType: 0 write: 0 login: 1 unknown: 1 onOff: 1 temp: 30, mode: 4 cP:1 uM:0 cTemp:1 acError:0
<-- 20 A1 0 39 1E 80 2C 0 mSrc: 32 mDst: 33 mType: 0 write: 0 login: 1 unknown: 1 onOff: 1 temp: 30, mode: 4 cP:0 uM:8 cTemp:22 acError:0
--> 21 81 0 39 1E 20 2D 0 mSrc: 33 mDst: 1 mType: 0 write: 0 login: 0 unknown: 1 onOff: 1 temp: 30, mode: 4 cP:1 uM:2 cTemp:22 acError:0
<-- 0 A0 0 39 1E A0 3 20 mSrc: 0 mDst: 32 mType: 0 write: 0 login: 1 unknown: 1 onOff: 1 temp: 30, mode: 4 cP:1 uM:10 cTemp:1 acError:0
<-- 20 A1 0 39 1E 80 2C 0 mSrc: 32 mDst: 33 mType: 0 write: 0 login: 1 unknown: 1 onOff: 1 temp: 30, mode: 4 cP:0 uM:8 cTemp:22 acError:0
--> 21 81 0 39 1E 20 2D 0 mSrc: 33 mDst: 1 mType: 0 write: 0 login: 0 unknown: 1 onOff: 1 temp: 30, mode: 4 cP:1 uM:2 cTemp:22 acError:0
<-- 0 A0 0 39 1E A0 3 20 mSrc: 0 mDst: 32 mType: 0 write: 0 login: 1 unknown: 1 onOff: 1 temp: 30, mode: 4 cP:1 uM:10 cTemp:1 acError:0
<-- 20 A1 0 39 1E 80 2D 0 mSrc: 32 mDst: 33 mType: 0 write: 0 login: 1 unknown: 1 onOff: 1 temp: 30, mode: 4 cP:1 uM:8 cTemp:22 acError:0
--> 21 81 0 39 1E 0 2D 0 mSrc: 33 mDst: 1 mType: 0 write: 0 login: 0 unknown: 1 onOff: 1 temp: 30, mode: 4 cP:1 uM:0 cTemp:22 acError:0
<-- 0 A0 0 39 1E A0 3 20 mSrc: 0 mDst: 32 mType: 0 write: 0 login: 1 unknown: 1 onOff: 1 temp: 30, mode: 4 cP:1 uM:10 cTemp:1 acError:0
<-- 20 A1 0 39 1E 80 2D 0 mSrc: 32 mDst: 33 mType: 0 write: 0 login: 1 unknown: 1 onOff: 1 temp: 30, mode: 4 cP:1 uM:8 cTemp:22 acError:0
--> 21 81 0 39 1E 0 2D 0 mSrc: 33 mDst: 1 mType: 0 write: 0 login: 0 unknown: 1 onOff: 1 temp: 30, mode: 4 cP:1 uM:0 cTemp:22 acError:0
<-- 0 A0 0 39 1E A0 3 20 mSrc: 0 mDst: 32 mType: 0 write: 0 login: 1 unknown: 1 onOff: 1 temp: 30, mode: 4 cP:1 uM:10 cTemp:1 acError:0
<-- 20 A1 0 39 1E 80 2D 0 mSrc: 32 mDst: 33 mType: 0 write: 0 login: 1 unknown: 1 onOff: 1 temp: 30, mode: 4 cP:1 uM:8 cTemp:22 acError:0
--> 21 81 0 39 1E 0 2D 0 mSrc: 33 mDst: 1 mType: 0 write: 0 login: 0 unknown: 1 onOff: 1 temp: 30, mode: 4 cP:1 uM:0 cTemp:22 acError:0
<-- 0 A0 0 39 1E A0 3 20 mSrc: 0 mDst: 32 mType: 0 write: 0 login: 1 unknown: 1 onOff: 1 temp: 30, mode: 4 cP:1 uM:10 cTemp:1 acError:0
<-- 20 A1 0 39 1E 80 2D 0 mSrc: 32 mDst: 33 mType: 0 write: 0 login: 1 unknown: 1 onOff: 1 temp: 30, mode: 4 cP:1 uM:8 cTemp:22 acError:0
--> 21 81 0 39 1E 0 2D 0 mSrc: 33 mDst: 1 mType: 0 write: 0 login: 0 unknown: 1 onOff: 1 temp: 30, mode: 4 cP:1 uM:0 cTemp:22 acError:0
<-- 0 A0 0 39 1E A0 3 20 mSrc: 0 mDst: 32 mType: 0 write: 0 login: 1 unknown: 1 onOff: 1 temp: 30, mode: 4 cP:1 uM:10 cTemp:1 acError:0
<-- 20 A1 0 39 1E 80 2D 0 mSrc: 32 mDst: 33 mType: 0 write: 0 login: 1 unknown: 1 onOff: 1 temp: 30, mode: 4 cP:1 uM:8 cTemp:22 acError:0
--> 21 81 0 39 1E 0 2D 0 mSrc: 33 mDst: 1 mType: 0 write: 0 login: 0 unknown: 1 onOff: 1 temp: 30, mode: 4 cP:1 uM:0 cTemp:22 acError:0
<-- 0 A0 0 39 1E A0 3 20 mSrc: 0 mDst: 32 mType: 0 write: 0 login: 1 unknown: 1 onOff: 1 temp: 30, mode: 4 cP:1 uM:10 cTemp:1 acError:0
<-- 20 A1 0 39 1E 80 2D 0 mSrc: 32 mDst: 33 mType: 0 write: 0 login: 1 unknown: 1 onOff: 1 temp: 30, mode: 4 cP:1 uM:8 cTemp:22 acError:0
--> 21 81 0 39 1E 0 2D 0 mSrc: 33 mDst: 1 mType: 0 write: 0 login: 0 unknown: 1 onOff: 1 temp: 30, mode: 4 cP:1 uM:0 cTemp:22 acError:0
<-- 0 A0 0 39 1E A0 3 20 mSrc: 0 mDst: 32 mType: 0 write: 0 login: 1 unknown: 1 onOff: 1 temp: 30, mode: 4 cP:1 uM:10 cTemp:1 acError:0
<-- 20 A1 8 38 1E 80 2D 0 mSrc: 32 mDst: 33 mType: 0 write: 1 login: 1 unknown: 1 onOff: 0 temp: 30, mode: 4 cP:1 uM:8 cTemp:22 acError:0
--> 21 81 0 38 1E 0 2D 0 mSrc: 33 mDst: 1 mType: 0 write: 0 login: 0 unknown: 1 onOff: 0 temp: 30, mode: 4 cP:1 uM:0 cTemp:22 acError:0
<-- 0 A0 0 38 1E 0 3 20 mSrc: 0 mDst: 32 mType: 0 write: 0 login: 1 unknown: 1 onOff: 0 temp: 30, mode: 4 cP:1 uM:0 cTemp:1 acError:0
<-- 20 A1 0 38 1E 80 2D 0 mSrc: 32 mDst: 33 mType: 0 write: 0 login: 1 unknown: 1 onOff: 0 temp: 30, mode: 4 cP:1 uM:8 cTemp:22 acError:0
--> 21 81 0 38 1E 0 2D 0 mSrc: 33 mDst: 1 mType: 0 write: 0 login: 0 unknown: 1 onOff: 0 temp: 30, mode: 4 cP:1 uM:0 cTemp:22 acError:0
<-- 0 A0 0 38 1E A0 3 20 mSrc: 0 mDst: 32 mType: 0 write: 0 login: 1 unknown: 1 onOff: 0 temp: 30, mode: 4 cP:1 uM:10 cTemp:1 acError:0

Focussing on my hardware differences, i am using a Lolin D32 board, I don't have the neopixel connected, and i don;t have a pushbutton connected.  Could there be any dependancies there?   I also am still having trouble adding the accessory to Home, it eventually worked but since flashing the debug frame line above i can;t add it - am going to remove that ine since it seems to have shown the issue is not comms with the fujitsu unit.
Is it expected that the serial terminal stops responding after about 30 sec on boot btw? I have to be quick to get my wifi settings done....

OK - I have progress.
I think it is some kind of lockup issue.
What I have proven over at least 2 dozen attempts is that the serial debug comms stops after as little as <30s when i am using the debug tools i.e. set wifi, pairing code, or as long as a couple of minutes when watching the LIN frame info stream past.
I did in fact catch the Home app communicating with the esp as shown below, but then the comms stopped - suspected board lockup.  Serial comms only comes back if I reset the board,
Any ideas?  Surely it has to be an Atom --> My D32 board difference....?  I am compliing in the latest released Arduino IDE, no errors, selecting the D32 board in the IDE...
Accessory configuration number: 1

Fujitsu AirConditioner is READY!

Trying to connect to NZ Police Rolleston.  Waiting 1 sec...
WiFi Connected!  IP Address = <IP_ADDRESS>

Starting MDNS...

HostName:      FUJIAC-E7D69027FCDC.local:80
Display Name:  Fujitsu AirConditioner
Model Name:    FUJIAC
Setup ID:      FUJI

Starting HAP Server on port 80 supporting 14 simultaneous HomeKit Controller Connections...

update(): coolingThresholdTemperature -> using midpoint 20C instead. <--- sucessfully comm with Home app!

Noted that if I press "W" in the serial terminal and scan for available wifi, then do not enter anything, it stays responsive for many minutes where normally it stops responding.... maybe that points to which area of code is in play.

SOLVED!
As usual, I feel a bit silly now, but will leave this issue here so others might benefit.
The “button” pin in the code happenned to map to a TOUCH sensor input on the dev board i used!  Naturally this pin had to be one that was unconnected ;-)
A floating input is never wise, but a sensitive touch sensor input..... well, it resulted in this issue and has been solved with a simple 10k pullup resistor.
If I had implemented the button this would never have come up, but the dev board is hidden behind the drywall behind the Fujitsu wall remote so I saw no need for a button.
ALWAYS check the basics.....
Thank you for your help @unreality and more so for this fantastic project. My Fujitsu ducted whole house HVAC now has a new lease on life, automations will be coming out my ears to turn it off when no one is home, preheat/cool the house on a schedule and all sorts of things.

Proven working fine more than a month later, check and doublecheck your hardware definitions is the lesson I learned :-)


Cannot use 'in' operator to search for 'settings' in null

I get this whenever I call .get on one of my services that's supposed to be localstorage.
My app
    let app = feathers()
      .configure(hooks())
      .configure(socketio(this.socket))
      .configure(authentication({ storage: window.localStorage }))
      .use('storage', localstorage({ storage: window.localStorage}))

And when I call
    app.service('storage').get('settings').then((settings) => foo(settings));

I get the error (which I could have caught)

TypeError: Cannot use 'in' operator to search for 'settings' in null

The first line in the stack points to my main.bundle.js (I'm using Webpack)
	  {
	    key: 'get',
	    value: function get(id) {
	      if (id in this.store) {
	        return Promise.resolve(this.store[id]);
	      }

	      return Promise.reject(new _feathersErrors2.default.NotFound('No record found for id \'' + id + '\''));
	    }
	  }

So clearly this.store is null. Didn't trace much further than that.

Fixed #9


Fix repository link on crates.io

https://github.com/DioxusLabs/dioxus-sdk -> https://github.com/DioxusLabs/sdk

Thanks! :dna:


test_models: panda safety tx test

sanity checks on the panda safety for sending standard openpilot messages.
asserts:

[x] We send all messages with empty CC message (nothing should be active)
[x] Cancel message works (in correct state)
[x] Resume message works

Looks good, just needs some cleanup


docs: update link

Codecov Report

Merging #31 into master will not change coverage.
The diff coverage is n/a.

@@          Coverage Diff          @@
##           master    #31   +/-   ##
=====================================
  Coverage     100%   100%
=====================================
  Files           3      3
  Lines         162    162
  Branches       24     24
=====================================
  Hits          162    162

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 68eda24...0e886d5. Read the comment docs.

:tada: This PR is included in version 1.5.11 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Map privacy settings for FREE plan let you write a password (+ error)

Steps

In a FREE account, go to the privacy options of a map. Only free is available but other options such as the password one allow to be "interacted"

Write something in the text box of the password

Press enter

There has been no activity on this issue for more several months. We are closing it. If you think this still needs to be addressed please open a new issue.


Old URL for myapps should be updated in the example

On the Send Invite example: https://myapps.azure.com is used when it should now point to https://myapps.microsoft.com

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: c7ea676e-0678-9e2d-e009-fb44587f93dd
Version Independent ID: 40b581da-26ea-2890-4a78-54b29f5dc610
Content: Quickstart: Add a guest user with PowerShell - Azure AD
Content Source: articles/active-directory/b2b/b2b-quickstart-invite-powershell.md
Service: active-directory
Sub-service: b2b
GitHub Login: @msmimart
Microsoft Alias: mimart

@the-blesss
Thanks for your feedback! We will investigate and update as appropriate.

True! The new experience is even updated to myapplications.microsoft.com. https://docs.microsoft.com/en-us/azure/active-directory/user-help/my-apps-portal-end-user-access
I'm assigning this to the author as the screenshot also needs to be updated.

Fixed in https://github.com/MicrosoftDocs/azure-docs/pull/49917
#please-close


Google Cloud Storage stopped working

The ability to upload cache artefacts to Google Cloud Storage stopped working

This should be fixed by the #10  pull request


Adds fallback to offline access token login

Adds a fallback for prod access with offline access tokens but adds a warning, and proceeds to use device code login for OCM when in the staging or integration environments.
Per some feedback received in slack this should allow both access mechanisms to give SREs more time to switch without breaking current prod workflows.

I walked through this with an expired OCM token and it worked fine.
But then I logged into OCM outside of the container and attempted to run this again and all logins worked fine.
Then I ran ocm logout outside of the container and attempted to run the container again, and now all environments fail to work.
This needs more work and testing before merging.

/hold
Based on @iamkirkbater's last comment

This is kind of a stopgap feature.
Given that offline tokens will be disabled in Prod soon and this won't be needed after then should we switch focus to getting the new login scheme working nicer?


TraceFactory

@theengineear @chriddyp @aneda @etpinard

@cldougl looks like you have some merge conflicts, I recently cleaned up some import statements, so it might be related to that. If you need help with that, feel free to ping me. Or, if you really don't feel comfortable with it, I can merge master into this branch for you.

mostly non-blocking comments, this is looking good! nice work

once tests pass, :dancer:

(also bump the version number!)

@cldougl it looks like you overwrote the commit message for the merge when you fixed conflicts here: https://github.com/plotly/python-api/commit/3a34763f525433175a7c2eb994b05f35af27364d
Typically, it's better for the git history to leave the original merge message (usually a one-liner) and just add your comments below.
Just a heads up :)

And same here, it's best to really take care of the merge in one commit AFAIK.
https://github.com/plotly/python-api/commit/bc52ff0ec9622e9b2ba993e1bde708767ad52118

just more git tips, it's also super helpful to comment on why you committed a change. because then you can just dropdown the additional information in GH, like you did here:

So, for example, it's unclear what the issue was with Python 3 that caused these changes (no need to comment now, but for future things like this) https://github.com/plotly/python-api/commit/9b2166e7d0160adb798dde26aa23c2f8d8cbf532, https://github.com/plotly/python-api/commit/2b5b7f7e43be7ac8fe21a8dd3d1573fe64513118, https://github.com/plotly/python-api/commit/053e4b6000969f563b67b9dd5f3d490a86d3d1df

Nice work on this!
https://www.youtube.com/watch?v=uTM2lnCkLBY
(:dancer:)


imported sacrebleu

Added reference BLEU implementation.

Great addition to the toolkit!  What do we think about creating a contrib directory for sacrebleu and other things we've discussed pulling in like a tokenizer or BPE?  Following the Moses model, contrib would be software distributed with Sockeye that--while not tightly integrated--makes for an all-in-one MT toolkit.  Over time, we can move some of the cool features we want, like automatically downloading and pre-processing data, into Sockeye modules (full integration, documentation, unit tests, etc.).  Until then, we can import independent tools into contrib.

@tdomhan, thanks for the tip, I'll add this.
@mjdenkowski I think putting it under contrib/ makes a lot of sense. I'll fix this in an amended commit, unless there are objections from others.

Pulled in master.

please kill me

Okay! I added effective bleu smoothing per @artemsok's request, and also added a test case for it to the unit tests. I think this is ready for a merge.


Update japicmp configuration for 1.16.2

As the title.

I don't know if it was missed or just for reasons I'm not aware of, it seems that the release of 1.16.1 did not update japicmp. If I understand correctly, we also should update it for bug-fix release. For safety reasons, could you please help confirm this @MartijnVisser. Thanks a lot!


call ignoreRoute with settled response object

Building ignoreRoute rules around the res.statusCode we're not previously possible.

I've also pushed a change here to specify sub-keys in req/res objects.
I wanted to include the remoteAddress from the response object, but req.connection is HUGE.
Now you can whitelist it like this
expressWinston.requestWhitelist.push("connection.remoteAddress");


macOS: When Atom window is closed and re-opened, the app completely rerenders

Prerequisites

[x] Can you reproduce the problem in safe mode?
[x] Are you running the latest version of Atom?
[x] Did you check the debugging guide?
[x] Did you check the FAQs on Discuss?
[x] Are you reporting to the correct repository?
[x] Did you perform a cursory search to see if your bug or enhancement is already reported?

Description
Everytime the Atom window is opened, it re-renders the whole UI. This is in contrast with the behavior of all the other macOS applications.
Usually when you close an application with the red button and then you re-open it from Dock, the UI is instantly available exactly as you left it when the window was closed.
Seems like there are two different problems:

The UI completely re-renders on window open
The window state is not preserved when the window is re-opened

Logically I have not checked "Open empty editor on start".
Steps to Reproduce

Open an Atom's window
Open a project, a file, a tab, whatever
Close the opened Atom's window using the red button
Click on the Atom icon in the Dock to re-open the window

Expected behavior: The window is instantly re-opened and I can continue from where I left.
Actual behavior: The window is created from scratch, takes several seconds to render its content, and once rendered, I have to reopen the tab/project I was using before I closed it.
Versions
~$ atom --version
Atom    : 1.11.0-dev-579e6b2
Electron: 0.37.8
Chrome  : 49.0.2623.75
Node    : 5.10.0
~$ apm --version
apm  1.12.5
npm  3.10.5
node 4.4.5
python 2.7.12
git 2.9.2

The same problem happens with all the Atom versions

I'm sorry, but I fail to see how that is expected behaviour from macOS.

Usually when you close an application with the red button and then you re-open it from Dock, the UI is instantly available exactly as you left it when the window was closed.

Not at all. Many single window/non document-based apps (such as slack, spotify) do that, but standard Apple apps (and 3rd party) don't.
Atom is document based, as many windows can be opened with different content.
Examples:

Open a safari window, and some tabs. Close it with the red button. Click on the safari icon. You get a new window, with your tab closed. Only the pinned tabs stay. Chrome works almost the same.
Open pages on a document saved on your drive. Close the window, open it using the doc, your document isn't loaded.
Sublime Text does the same

Non document apple apps work the way you describe though:

iTunes
Messages
Calendar

The only times document based window apps restore their windows, is if it is enabled in your macOS settings, and you quit the app (Cmd Q) rather than closing the windows. In document based apps, the red button means you want to close the specific document window, not hide it.

@abarisain yours are good points, but the only official Apple IDE (Xcode) re-opens the document when you re-open the app.
Also, in Atom I have not checked "Open empty editor on start" and the autosave session plugin is enabled, so I would expect Atom to re-open my last session.

Atom is not an IDE, it is closer to TextEdit (file editing) than Xcode (file editing, simulating, debugging, testing, etc…). And TextEdit is document based, thus I expect Atom to work like TextEdit.

@FezVrasta  When re-opening, sure. Atom does that for me too. (Talking about Cmd-Q)
But, if I click on Xcode's doc icon after closing the last project window (using the red button), it will show me the welcome screen, which allows me to pick a project.

Then you've got another issue that the one described here, which is why we got confued
My only argument was that atom should not restore the workspace once you close the last window using the red button, rather than quitting it with Cmd-Q.
I agree about the rendering time, but it allows the editor to free the ram used by an open editor window. It's a huge downside of electron, the first display time of a window is pretty slow.

I fixed the bug https://github.com/atom/atom/pull/12486,
@50Wliu could you review this code when you get a chance? I tested it on macOS and  everything seemed ok.

Does this patch makes it so when you close atom's last window (but not the app!), clicking the dock icon opens the last closed window, or will it open an empty editor?

@abarisain  it will open the last closed window !

I don't understand why that is the expected behaviour, as it is totally opposed to what other OSX apps do (sublime, Xcode, etc...)

Checking "Open Empty Editor On Start" will make it so atom always opens an empty editor, disregarding last state.
Unchecking it makes it behave like a normal osx app.

About the CMD Q I confirm that it doesn't restore the state once Atom is started over.

That's another issue, I think. "Open Empty Editor On Start" seems to be totally bugger. Whatever its state is, it shouldn't stop Atom's status to be restored when the app is quitted with opened windows.
I was merely expressing my disagreement that #12486 fixes this issue, as it introduces (to my eyes) an unwanted behaviour :)

I'm having this same problem. I've tried the latest beta and it's still an issue.


TracingConsumer can not poll message from kafka

Describe the Bug
A clear and concise description of what the bug is. If you have a solution in mind, skip raising an issue and open a pull request instead.
when i send to message to kafka using TracingProducer, I poll message from kafka using TracingConsumer and get nothing

and there is no spans about consumer.
Steps to Reproduce
Steps to reproduce the behavior:
first: Using TracingProducer to send message to kafka (report to zipkin);
sencond: Using TracingProducer to send message to kafka (report to zipkin);
Expected Behaviour
The best is to spend some time to write a failing test. Bugs with tests get fixed and stay fixed.
i can see the message polled from kafka and find the span on zipkin

hi this is probably more support in nature. Can you use gitter instead? when you go there, please tell us where your demo code is (maybe it is in github). possibly there is a configuration mistake https://gitter.im/openzipkin/zipkin

here is the demo project，when i use kafka native api，everything goes well.
------------------ 原始邮件 ------------------
发件人: "Adrian<EMAIL_ADDRESS>发送时间: 2019年6月12日(星期三) 上午8:08
收件人<EMAIL_ADDRESS>抄送<EMAIL_ADDRESS><EMAIL_ADDRESS>主题: Re: [apache/incubator-zipkin-brave] TracingConsumer can not pollmessage from kafka (#922)
Closed #922.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.


TypeError: Cannot destructure property readFile of 'undefined' or 'null'.

I installed the near-shell npm module using 'npm install -g near-shell', But I am getting Type error when checking the near version 'near --version' -
/usr/local/lib/node_modules/near-shell/commands/dev-deploy.js:4
const { readFile, writeFile, mkdir } = require('fs').promises;
^
TypeError: Cannot destructure property readFile of 'undefined' or 'null'.
at Object. (/usr/local/lib/node_modules/near-shell/commands/dev-deploy.js:4:53)
at Module._compile (module.js:653:30)
at Object.Module._extensions..js (module.js:664:10)
at Module.load (module.js:566:32)
at tryModuleLoad (module.js:506:12)
at Function.Module._load (module.js:498:3)
at Module.require (module.js:597:17)
at require (internal/module.js:11:18)
at Object. (/usr/local/lib/node_modules/near-shell/bin/near-cli.js:195:14)
at Module._compile (module.js:653:30)

thanks for posting @rahul70392, can you share some of your system details with us here please?
you can run this command to share the version of Node.js you are using
node -v

and this command for a few more details about your operating system
npx systeminformation

(see more here: https://www.npmjs.com/package/systeminformation)
the os node of the resulting JSON object will be useful for us to try to reproduce this error.  here's the report from my system
{
  "os": {
    "platform": "darwin",
    "distro": "Mac OS X",
    "release": "10.15.5",
    "codename": "macOS Catalina",
    "kernel": "19.5.0",
    "arch": "x64",
    "hostname": "bigbuk.local",
    "codepage": "UTF-8",
    "logofile": "apple",
    "serial": "54F1A78D-6F41-32BD-BFED-4381F9F6E2EF",
    "build": "19F101",
    "servicepack": "",
    "uefi": true
  }

This issue is more appropriate for near-shell repository.


added missing last_reset to sensor for metering (electricity,gas, water etc.)

Table of Contents generated with DocToc

Description
License Acceptance
Type of changes
Checklist

Description
Sensors has an optional attribute last_reset read
https://developers.home-assistant.io/docs/core/entity/sensor/#properties
License Acceptance

[x] This repository is Apache version 2.0 licensed and by making this PR, I am contributing my changes to the repository under the terms of the Apache 2 license.

Type of changes

[ ] Add/update a helper script
[ ] Add/update link to an external resource like a blog post or video
[x] Bug fix
[ ] New feature
[ ] Test updates
[ ] Text cleanups/updates

Checklist

[ ] I have read the CONTRIBUTING document.
[ ] All new and existing tests pass.
[ ] Any scripts added use #!/usr/bin/env interpreter instead of potentially platform-specific direct paths (#!/bin/sh is an allowed exception)
[ ] Scripts added/updated in this PR are all marked executable.
[ ] Scripts added/updated in this PR do not have a language file extension unless they are meant to be sourced and not run standalone. No one should have to know if a script was written in bash, python, ruby or whatever. Not including file extensions makes it easier to rewrite the script in another language later without having to change every reference to the previous version.
[ ] I have confirmed that any links added or updated in my PR are valid.

@unixorn could you check please whats wrong?

Nice perfect and thank you @unixorn

@unixorn I dont want make pressure, but for my addon I need this change, to continue my work 😅

Sorry about the delay, been a busy week at work. It's pushed to pypi now as 0.16.2.

When your addon is complete, please PR in a link to it in the readme. What does your addon do?

read the measurments from viessmann gridbox the PV and battery


Save TCP port in connect, add value to Host header in send_request.

This is required by HTTP RFC when communicating with a server on the non-default TCP port.

Hi, Is this not going to also add the port when connecting to the default 80/443 ports?

This patch adds it in all cases. I'm pretty sure that's OK because the HTTP spec marks the port as required if you are not communicating on the default port but doesn't disallow it in other cases. From my reading HTTP servers must accept if you're doing HTTP on port 80 or HTTPS on 443.
From the 1.1 spec:
"A "host" without any trailing port information implies the default port for the service requested (e.g., "80" for an HTTP URL)."
https://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.23
If you feel strongly that I should go back and omit it on :80 or :443 I can do that but it doesn't appear to be necessary.

Yeah, I don't think it should be a problem but... I think adding :80 or :443 to the host header could well break various applications that aren't expecting it.
I know that many of the PHP apps etc we have on origin servers would start doing weird stuff in that scenario as they rely on the Host header having just the hostname in it and no port.

Fair enough. I'll go back, tweak it, and send you an updated version.

I updated the code. I'm not super happy with it though.
The two changes are forcing the port number to be a number in parse_uri and then in send_request if the port is not 80 or 443 the Host header is constructed with the port. This code will NOT deal with HTTPS on 80 or HTTP on 443 but that's a (hopefully) very rare situation so it may be OK.
I wrote a better check in request_uri (comparing the scheme and port) but I'm not comfortable enough with the rest of the code to be certain that that's the only code path I need to change.

Yeah it's a little tricky as we don't actually know what the scheme is on the 'generic' interface path.
Will see what James says on Thursday :)


Automatically activate valid certificates if available

Describe the bug
Currently, it's possible for the active certificate to be invalid, while having other valid certificates available. These can be activated from the settings page, but this is unintuitive. I would be much better UX for the active certificate to be updated automatically to a valid cert if one is available.
The bug aspect of this is the many ways in which a user can be told they have a valid cert, when they don't, or vice-versa.
Additional context
Currently the active cert is stored in an atom. This should be changed to a getter function that returns a cached value, and can update the value if it's appropriate to do so.
Note: This change would have require significant re-work of the various pages that use the certificate, so it could be time consuming and has a higher risk of introducing regressions. Time for development and testing should be planned accordingly.

Hi @jtary and @anilmurty, wanted to take this up!!

Thanks @yshsaxena - please go ahead!

hi @jtary, is only one cert can remain active at a time?

@yshsaxena - correct.

Hi @yshsaxena - are you still working on this?


⚠ Bofrost.com has degraded performance

In ffa5657, Bofrost.com (https://www.bofrost.com) experienced degraded performance:

HTTP code: 200
Response time: 1641 ms

Resolved: Bofrost.com performance has improved in aa9233c after 6 minutes.


Properly handle gssapi errors.

Codecov Report

Merging #171 into master will decrease coverage by <.01%.
The diff coverage is 50%.

@@            Coverage Diff             @@
##           master     #171      +/-   ##
==========================================
- Coverage   53.36%   53.35%   -0.01%
==========================================
  Files         340      340
  Lines       26190    26194       +4
  Branches     3417     3417
==========================================
+ Hits        13975    13977       +2
+ Misses      11514    11507       -7
- Partials      701      710       +9

Impacted Files
Coverage Δ

lib/python/treadmill/cli/admin/__init__.py
49.05% <50%> (+0.07%)
:arrow_up:

lib/python/treadmill/sproc/zk2fs.py
41.07% <0%> (ø)
:arrow_up:

lib/python/treadmill/services/localdisk_service.py
77.04% <0%> (ø)
:arrow_up:

lib/python/treadmill/state.py
0% <0%> (ø)
:arrow_up:

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update f2c9fe6...f5262e2. Read the comment docs.


[MINOR] Fix CodeStyle Error for ExpressionImplUtilsSuite

What changes were proposed in this pull request?
The pr is following up https://github.com/apache/spark/pull/46845, to fix  dev/scalastyle check error.
Why are the changes needed?
Make sh dev/scalastyle hadppy.
Does this PR introduce any user-facing change?
No.
How was this patch tested?
Manually test
sh dev/scakastyle

Before:
(base) ➜  spark-community git:(master) ✗ sh dev/scalastyle
-e Scalastyle checks failed at following occurrences:
[error] /Users/panbingkun/Developer/spark/spark-community/sql/catalyst/src/test/java/org/apache/spark/sql/catalyst/expressions/ExpressionImplUtilsSuite.scala:394:28: nonascii.message
[error] /Users/panbingkun/Developer/spark/spark-community/sql/catalyst/src/test/java/org/apache/spark/sql/catalyst/expressions/ExpressionImplUtilsSuite.scala:396:28: nonascii.message
[error] Total time: 23 s, completed Jun 26, 2024, 9:49:06 AM

After:
(base) ➜  spark-community git:(fix_scalastyle) ✗ sh dev/scalastyle
-e Scalastyle checks passed.

Was this patch authored or co-authored using generative AI tooling?
No.

cc @HyukjinKwon @cloud-fan @uros-db

let me merge it now to unblock the CI.


Frame Targets?

It's possible to manage Frame Targets? In which way?
Thank You

Hi Antonio,
At the moment, when launching the plugin you specify a local database, along with an array or images you're looking for in this session.
Hope that helps?


Memory leak under Rack::Test

We've been writing our API using Grape and the DSL is great! However as we write more endpoints and test them with RSpec we've seen memory utilization skyrocket! Upwards of 8+G to test ~7 endpoints!
I wrote a spec file to try and isolate the problem and noticed three classes that with every call to an endpoint leave behind numerous objects that cannot be garbage collected.
Here is the spec I wrote that shows the increase in references for these classes:
Grape::Route, Grape::Endpoint,Grape::Util::HashStack,Regexp
And after 3 calls to the endpoint, I saw the reference counts go from
"Grape::Route 25 references"
"Grape::Endpoint 36 references"
"Grape::Util::HashStack 50 references"
"Regexp 4386 references"

to
"Grape::Route 47 references"
"Grape::Endpoint 47 references"
"Grape::Util::HashStack 60 references"
"Regexp 4687 references"

require 'spec_helper'

class GcApi < Grape::API
  prefix 'gcapi'
  format :json

  resources :testing do
    get do
      true
    end

    put do
      false
    end
  end
end

UserTesting::Orders::Application.routes.draw do
  mount GcApi => '/'
end

describe GcApi do
 include Rack::Test::Methods
 def app
   subject
 end

  def log(object, message)
    header = "*"*20 + message + "*"*20
    p header
    p object
    p "*"*header.length
  end

  def dumpit(file)
    counts = Hash.new{ 0 }
    ObjectSpace.each_object do |o|
      counts[o.class] += 1
    end
    file = File.open(file, 'w')
    counts.each do |key, val|
      file.puts(key.to_s + "=" + val.to_s)
    end
    file.close
  end

  def show_references(klass)
    count = 0
    ObjectSpace.each_object(klass) do |o|
      count += 1
    end
    p klass.to_s + " #{count} references"
  end

  def accept_header
    { 'HTTP_ACCEPT' => "application/json" }
  end

  before(:all) do
    GC.start
    log ObjectSpace.count_objects, "BEFOREALL"
    # dumpit("before.txt")
    show_references(Grape::Route)
    show_references(Grape::Endpoint)
    show_references(Grape::Util::HashStack)
    show_references(Regexp)
  end

  after(:all) do
    show_references(Grape::Route)
    show_references(Grape::Endpoint)
    show_references(Grape::Util::HashStack)
    show_references(Regexp)
    GC.start
    log ObjectSpace.count_objects, "AFTERALL"
    # dumpit("after.txt")
  end

  it "should run quickly" do #1635
    get "/gcapi/testing.json", nil, {}
    last_response.body.should == "true"
  end

  it "should run longer" do #1635
    get "/gcapi/testing.json", nil, {}
    last_response.should be_empty # false assumption
  end

  it "should run quickly or maybe not" do #409
    put "/gcapi/testing.json", nil, {}
    last_response.body.should == "false"
  end

  # it "should be able to GC" do
  #   GC.start
  #   sleep 5
  #   log ObjectSpace.count_objects, "BEFORESIMPLETEST"
  #   (1+1).should eql(2)
  #   GC.start
  #   sleep 5
  #   log ObjectSpace.count_objects, "AFTERSIMPLETEST"
  # end
end

@slauwers @mattsnyder I spent a bit of time on this, using code in https://github.com/dblock/grape-on-rack/pull/8.
First, I cannot reproduce the fact that every get generates a new Endpoint reference (or anything runaway). Make sure to add GC.start in an after block to get consistent output.
  after(:all) do
    GC.start
    @stats.collect!
    @stats.display
  end

I can however consistently reproduce that every time we declare an API it doesn't get GC-ed between tests. This is normal, if you're going to create a new type that inherits from Grape::API, it mounts endpoints and holds onto them. But that's not a leak.
module Acme
  class API < Grape::API
  ...
  end
end

Here Acme::API will hold onto its endpoints every time, you can examine Acme::API.endpoints to see them.
Help me see a leak here where iterating over something produces a very large number of allocated objects?

I was only seeing it under test
Sent from my iPhone

On Jan 2, 2015, at 1:27 PM, Daniel Doubrovkine (dB.) @dblockdotorg<EMAIL_ADDRESS>wrote:
@slauwers @mattsnyder I spent a bit of time on this, using code in dblock/grape-on-rack#8.
First, I cannot reproduce the fact that every get generates a new Endpoint reference (or anything runaway). Make sure to add GC.start in an after block to get consistent output.
after(:all) do
GC.start
@stats.collect!
@stats.display
end
I can however consistently reproduce that every time we declare an API it doesn't get GC-ed between tests. This is normal, if you're going to create a new type that inherits from Grape::API, it mounts endpoints and holds onto them. But that's not a leak.
module Acme
class API < Grape::API
...
end
end
Here Acme::API will hold onto its endpoints every time, you can examine Acme::API.endpoints to see them.
Help me see a leak here where iterating over something produces a very large number of allocated objects?
—
Reply to this email directly or view it on GitHub.

@mattsnyder That's totally fine, I still would like a way to see it myself ;)

@dblock Having a look at this now. Will get back to you ASAP.

@dblock Indeed, this may not have been clear in my previous comments, I was unable to reproduce an issue where upon each GET request there was un-GC'd data. I tried from fresh to try and isolate something, however was unsure whether what I was showing was a leak or not. Hence my comment:

Is this sufficient to show that there is a leak, or do you need me to dig in further?

I do however notice this problem (the leaks) in my software. I can't post results of OStats on my software, considering I'm using Sequel and this seems to mess with o.class.name; I'm getting a lot of nil errors if I attempt to use OStat.
I can't work on this any further today, however I'll try to clear some time during the week to reproduce the issue in test. Sorry for the waste of time.

Thanks @slauwers, looking forward to hearing from you.

For anyone having similar trouble and thinking it is Grape's memory leak, please check if you are not doing what is described below.
Here's rough reproduction of what seems like a Grape leak:
require 'grape'
require 'rack/test'

class TestCl < Grape::API
  prefix "api"

  get do
  end
end

describe TestCl do
  include Rack::Test::Methods

  let(:app) { subject }

  100.times do
    it "returns all when get '/'" do
      get "api/"
      expect(1).to eq 1
    end
  end

end

The specs above gradually slow down to almost-infinity devouring away your resources.
Here's how to 'fix' it:
require 'grape'
require 'rack/test'

class TestCl < Grape::API
  prefix "api"

  get do
  end
end

describe "TestCl" do
  include Rack::Test::Methods

  let(:app) { TestCl }

  100.times do
    it "returns all when get '/'" do
      get "api/"
      expect(1).to eq 1
    end
  end

end

I.e. point the app to your actual Grape::API class, and not to the subject reference.

@yr0 Thanks a bunch. This has indeed solved the problem I was having. @dblock, I guess we can close this one.

This makes sense. Every time you use subject it creates an instance of TestCl, which does work, but never gets GCed and is not what you're supposed to use since Grape APIs are classes, not instances. I'd appreciate if @slauwers and @yr0 could quickly parse through Grape tests and README and see if we do this anywhere and potentially PR some doc. Otherwise I think it's one of those gotchas and people will make this "mistake" anyway. Closing this issue.

@grape: I'm in the process of leaving the company this account is linked
to, so doing any kind of work on this during business hours is going to be
tricky. I'll see if I can work through this in my spare time, on my
@teotwaki account.
On 1 April 2015 at 14:06, Daniel Doubrovkine (dB.) @dblockdotorg <
<EMAIL_ADDRESS>wrote:

This makes sense. Every time you use subject it creates an instance of
TestCl, which does work, but never gets GCed and is not what you're
supposed to use since Grape APIs are classes, not instances. I'd appreciate
if @slauwers https://github.com/slauwers and @yr0
https://github.com/yr0 could quickly parse through Grape tests and
README and see if we do this anywhere and potentially PR some doc.
Otherwise I think it's one of those gotchas and people will make this
"mistake" anyway. Closing this issue.
—
Reply to this email directly or view it on GitHub
https://github.com/intridea/grape/issues/665#issuecomment-88452241.


rocAL Audio unit test minor fix

Fix the return value of the Non silent region output verify function

@LakshmiKumar23 can you review this change. Thanks!

@kiritigowda can we merge this once CI passes? QA is waiting on this PR


Change replication.enabled with replicaSet.enabled

The current suggested command line is wrong.

What this PR does / why we need it:
Which issue this PR fixes
(optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close that issue when PR gets merged)

fixes #

Special notes for your reviewer:
Checklist
[Place an '[x]' (no spaces) in all applicable fields. Please remove unrelated fields.]

[ ] DCO signed
[ ] Chart Version bumped
[ ] Variables are documented in the README.md

@sabbour could you please bump the chart version and add signoff to make the linter pass?

@vsliouniaev I actually only changed the README. Does it warrant a bump?

Yep, charts are completely atomic, so lint will fail if you don't update the readme

Hi @sabbour
Thanks for the PR! As @vsliouniaev mentioned you need to signoff your commit and increase the patch version in the Chart.yaml
It's mandatory for the CI

Sorry @juan131 bear with me as this was my first PR here. It seems I can't get this sign-off thing to work.

It seems you also included changes from other charts. My recommendation: start from scratch.

Close this PR
Create a new branch with the changes on MongoDB chart and when you commit the changes remember to add the flag --signoff.
Create a new PR with those changes

Yeah git wouldn’t let me commit again without merging upstream changes.
Ok will do.
/close

Ahmed

From: Juan Ariza Toledano<EMAIL_ADDRESS>Reply-To: helm/charts<EMAIL_ADDRESS>Date: Thursday, November 15, 2018 at 1:06 PM
To: helm/charts<EMAIL_ADDRESS>Cc: Ahmed Sabbour<EMAIL_ADDRESS>Mention<EMAIL_ADDRESS>Subject: Re: [helm/charts] Change replication.enabled to replicaSet.enabled (#9264)
It seems you also included changes from other charts. My recommendation: start from scratch.

Close this PR
Create a new branch with the changes on MongoDB chart and when you commit the changes remember to add the flag --signoff.
Create a new PR with those changes

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fhelm%2Fcharts%2Fpull%2F9264%23issuecomment-438968429&data=02|01|asabbour%40microsoft.com|392a046037334492973108d64ad99eff|72f988bf86f141af91ab2d7cd011db47|1|0|636778695867181051&sdata=FHcIil%2FJ3A7RhmcO05jnS03uFVftTss8sjDk9gKSKYU%3D&reserved=0, or mute the threadhttps://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAAGVsODvIlMBIysICfX_ba3lYO88CHkQks5uvS6RgaJpZM4YdpT7&data=02|01|asabbour%40microsoft.com|392a046037334492973108d64ad99eff|72f988bf86f141af91ab2d7cd011db47|1|0|636778695867181051&sdata=rKLACFx2CT3RaNAsfk3l%2FWHkQeetOel92hrNTrmYFfM%3D&reserved=0.

/close


Allowing custom parameters to be set in the signin request.

Hey, I am using this library for implementing the implicit flow and the I want to send a custom parameter (realm_id) in the authorization url.
It'll be great if there's an option of adding a custom parameter in the sign in url.
Thank you !

What's realm_id? Is that in the spec?

This is a custom field being used by our app. A realm is used for grouping clients. A realm_id is then further used for authorization.
This is not in specs, it would be awesome if there's a way to add a custom params in the signin url.
Editing the initial comment.

If you're using IdentityServer then we recommend using acr_values=idp:yourrealm as a home realm hint.

Hey, we are using an in-house IAM server which expects a realm_id in the signin url. This logic is very custom to satisfy some business requirements. Adding a way to add custom parameters, maybe a callback which gets called just before the signin url is formed, would make this library more flexible to use.
Nimbus OAuth SDK does provide a way to add custom parameters, please find this below:
https://connect2id.com/products/nimbus-oauth-openid-connect-sdk/examples/oauth/authorization-request

I would gladly like to have this feature as well for a different use case. When authenticating with google's authority, you can provide an extra parameter called hd to limit the host domain that people can use to sign in. This is mostly a cosmetic thing but it can also help users with multiple google accounts (like people with a personal gmail account and a work google apps account) to use the right one when signing in.

Understood. The current issue is that right now the param is an object and we look for explicit protocol params. I'd need to figure out how to indicate other params that are custom/non-protocol to include.

Something like this would be good. I am currently using the userManager.createSigninRequest, then append the custom parameters to the URL and redirect myself.
Passing it (somehow) as a signinRedirect parameter would be nice. (Maybe the createSigninRequest(args) method or _signinStart(args) of the UserManager is a good place to do this? Idk. )

I agree. We want to send a custom parameter from the client, because we use Kentor Authservice which redirects to a Federation. If we supply an EntityId as a parameter the Federation's Discovery Service gets overriden and user is redirected to the correct IDP (instead of choosing one from the DS).

Hi guys, do ye have a sense as to when this might be fixed? (ie. when might https://github.com/IdentityModel/oidc-client-js/pull/355 be merged?).
It would be great to have access to this functionality soon in my scenarios.
Thanks for a great project!

Not for a bit -- I'm traveling.

Thanks for the the update @brockallen. Have a good trip!

Done, thanks!

Thanks for the changes!
For posterity:
const userManager = new UserManager({ ... }); //as normal
await userManager.signinRedirect({
    extraQueryParams: { //your params go here
        foo: 'bar',
        batz: 'quux',
    },
});

So, I don't want the extra param encoded into the ReturnUrl (state). I need send over the app's language so the login can be in the currect language. Any way to do that?
/?culture=fr-CA&ReturnUrl=....

Per spec, you want the ui_locales param: https://openid.net/specs/openid-connect-core-1_0.html#AuthRequest

I'll have to research if there is a way to get .NET Core's IdentityServer4 to handle it. Thanks!

@sikemullivan they should be in Parameters of AuthorizationRequest


Removed hack extension

This PR removes the hack extension. With recent updates to Azure this extension's main uses are obviated. I am maintaining a branch on my personal fork in case we decide to bring it back.

This checklist is used to make sure that common guidelines for a pull request are followed.

For new extensions:

[ ] My extension description/summary conforms to the Extension Summary Guidelines.

About Extension Publish
There is a pipeline to automatically build, upload and publish extension wheels.
Once your PR is merged into master branch, a new PR will be created to update src/index.json automatically.
The precondition is to put your code inside this repo and upgrade the version in the PR but do not modify src/index.json.

Removed hack


Message format not dependend on firmware

The message format <DAQPRJ> ... </DAQPRJ> is not (just) dependend on the firmware, but changes with different settings made within the Nano-PK.
The README.md is missleading since it states the out of the box support for several firmwares.
The standard case should be to pull the message format in any case. And also after changing major settings if needed.

It is not possible to easily pull the message format from the network data, unfortunately. The DAQPRJ block is only written to SD card when logging is enabled, as far as I am aware it is never sent over the network.
What makes you think that the message format changes depending on your settings?

Yes, by pulling I ment getting the message format with the SD card. Sorry, I should have explained a little more.
Past week I had to change a major setting related to the number of suction points of the pellet storage. The message format was different afterwards, since additional data related to the suction points was sent.
So I am pretty shure, that the message format is related to the settings and the setup respectively. It is probably also relying on the firmware but not only on it.
I would suggest getting the message format with the SD card should be the standard way. The given message formats within this packet might confuse people if they have the same firmware but it is not working.

That would explain why I couldn't get the integration to work with the NANO_V14N2 setting while I was on this exact firmware when initially setting up the integration last year. It wasn't until I defined the msgformat manually that I could get it to work. Would make sense to sharpen the documentation a bit in that regard.

I actually noticed this today after we had a technician over. The format changed and the integration broke after he seemed to change some settings, despite the same firmware/version still being present.


Replace assert by simpler but equivalent calls.

Coverage decreased (-0.09%) to 98.291% when pulling fdc7035d077e27bdc510dbe65950372920e5f632 on arturobernalg:feature/simplify into 93a9affacf54011487d26b453b7f1ad18990f61c on apache:master.


Elastalert in standalone mode

It looks like the new rule loading has somewhat broken standalone elastalert usage with --start and --end options.
E.g. for the same (rather simple) rules and configs I can see following output for elastalert 0.1.39:
/usr/bin/python -W ignore -m elastalert.elastalert --config /root/alert-config.yml --rule /root/alert-rule.yml  --start 2020-01-30T22:08:00 --end 2020-01-30T22:18:00 --debug
INFO:elastalert:Note: In debug mode, alerts will be logged to console but NOT actually sent.
            To send them but remain verbose, use --verbose instead.
INFO:elastalert:Starting up
INFO:elastalert:Queried rule ams02-c01-alr00-01 from 2020-01-30 22:08 UTC to 2020-01-30 22:13 UTC: 25 / 25 hits
INFO:elastalert:Queried rule ams02-c01-alr00-01 from 2020-01-30 22:13 UTC to 2020-01-30 22:18 UTC: 23 / 23 hits
INFO:elastalert:Alert for ams02-c01-alr00-01 at 2020-01-30T22:13:02.028Z:
INFO:elastalert:ams02-c01-alr00-01

Less than 5 unique logstash_processor(s) occurred since last alert or between 2020-01-30 22:08 UTC and 2020-01-30 22:13 UTC

@timestamp: 2020-01-30T22:13:02.028Z
num_hits: 48
num_matches: 1

INFO:elastalert:Skipping writing to ES: {'hits': 48, 'matches': 1, '@timestamp': '2020-01-30T22:54:49.959795Z', 'rule_name': 'ams02-c01-alr00-01', 'starttime': '2020-01-30T22:08:00Z', 'endtime': '2020-01-30T22:18:00Z', 'time_taken': 0.05319690704345703}
INFO:elastalert:Ran ams02-c01-alr00-01 from 2020-01-30 22:08 UTC to 2020-01-30 22:18 UTC: 48 query hits (0 already seen), 1 matches, 0 alerts sent

but elastalert 0.2.1 stops execution after loading rules:
/usr/bin/python3 -W ignore -m elastalert.elastalert --config /root/alert-config.yml --rule /root/alert-rule.yml  --start 2020-01-30T22:08:00 --end 2020-01-30T22:18:00 --debug
INFO:elastalert:Note: In debug mode, alerts will be logged to console but NOT actually sent.
                To send them but remain verbose, use --verbose instead.
INFO:elastalert:Note: In debug mode, alerts will be logged to console but NOT actually sent.
            To send them but remain verbose, use --verbose instead.
1 rules loaded
INFO:elastalert:Starting up

Contents of the files do not change between the runs and appear to be pretty simple:
/root/alert-config.yml
alert_time_limit:
  days: 2
buffer_time:
  minutes: 5
es_host: <IP_ADDRESS>
es_port: 9200
rules_folder: /etc/elastalert/autogen/rules/
run_every:
  minutes: 5
writeback_index: elastalert_status

/root/alert-rule.yml
alert:
- command
cardinality_field: logstash_processor
command: /usr/bin/cat -
filter:
- query_string:
    query: '*'
index: '*logs-lbs-trace*'
is_enabled: true
min_cardinality: 5
name: ams02-c01-alr00-01
pipe_alert_text: true
pipe_match_json: false
realert:
  minutes: 0
timeframe:
  minutes: 5
timestamp_field: '@timestamp'
timestamp_type: iso
type: cardinality

Should elastalert from 0.2.0 be running only as a daemon and --end option should not be used?
Or am I missing something in the logic and it could be run as a run-once standalone application?

I got the same issue with --start and --end options set altogether. If --end is omited, elastalert works.
After having investigated in the code, it seems that the "start" function does not handle the endtime and the next_run time correctly.
The next_run corresponds to the current time + the run_every time interval:
next_run = datetime.datetime.utcnow() + self.run_every
The endtime corresponds to what has been provided in command line.
However both values are compared together whereas we do not care about the next_run when running with start and end options.
Here is an extract of the start function:
`
while self.running:
next_run = datetime.datetime.utcnow() + self.run_every
        # Quit after end_time has been reached
        if self.args.end:
            endtime = ts_to_dt(self.args.end)

            if next_run.replace(tzinfo=dateutil.tz.tzutc()) > endtime:
                exit(0)

Since my endtime is in the past compared to next_run, the program exits directly. Commentingexit(0)` allows to start the program but then it never finishes.
I do not know precisely how to fix the issue. But if someone can, that will be really welcome.
Thanks.
Pierre

I have made a workaround for this.
If a rule reaches the "end" for itself I remove it from the list (it can also be just disabled instead). Then I added the condition if there are no running rules "elastalert" quits.
This works fine for me and I hope it may help some. Although after the rule ends you have to wait for "run_every" duration before the condition check and process exits.
In elastalert.py:
@@ -1164,12 +1164,15 @@
             next_run = datetime.datetime.utcnow() + self.run_every

             # Quit after end_time has been reached
-            if self.args.end:
+            if self.args.end and not self.args.start:
                 endtime = ts_to_dt(self.args.end)

                 if next_run.replace(tzinfo=dateutil.tz.tzutc()) > endtime:
                     exit(0)

+            if len(self.rules) == 0:
+                exit(0)
+
             if next_run < datetime.datetime.utcnow():
                 continue

@@ -1277,6 +1280,13 @@
                                    " %s alerts sent" % (rule['name'], old_starttime, pretty_ts(endtime, rule.get('use_local_time')),
                                                         self.thread_data.num_hits, self.thread_data.num_dupes, num_matches,
                                                         self.thread_data.alerts_sent))
+
+            if hasattr(self.args, 'end') and self.args.end:
+                # redundant?
+                if endtime == ts_to_dt(self.args.end):
+                    self.rules = [running_rule for running_rule in self.rules if running_rule['name'] != rule['name']]
+                    self.scheduler.remove_job(job_id=rule['name'])
+                    elastalert_logger.info('Rule %s removed', rule['name'])
+
             self.thread_data.alerts_sent = 0

             if next_run < datetime.datetime.utcnow():


Integration broken in 2023.8 beta

Checklist

[X] I have updated to the latest available Proxmox VE Custom Integration version.

Describe the issue you are experiencing
The integration can not be loaded in 2023.8.0b1
I get this error:
raceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/config_entries.py", line 388, in async_setup
    result = await component.async_setup_entry(hass, self)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/config/custom_components/proxmoxve/__init__.py", line 435, in async_setup_entry
    device_info(
  File "/config/custom_components/proxmoxve/__init__.py", line 521, in device_info
    return device_registry.async_get_or_create(
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/helpers/device_registry.py", line 511, in async_get_or_create
    device_info_type = _validate_device_info(config_entry, device_info)
                       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/helpers/device_registry.py", line 165, in _validate_device_info
    raise DeviceInfoError(
homeassistant.helpers.device_registry.DeviceInfoError: Invalid device info {'configuration_url': 'https://<IP_ADDRESS>:8006/#v1:0:=node/pve', 'default_manufacturer': 'Proxmox VE', 'default_model': 'Intel(R) Core(TM) i3-10100 CPU @ 3.60GHz', 'entry_type': <DeviceEntryType.SERVICE: 'service'>, 'hw_version': None, 'identifiers': {('proxmoxve', 'xxx_NODE_pve')}, 'name': 'Node pve', 'sw_version': 'Proxmox 8.0.3', 'via_device': ('', '')} for 'proxmoxve' config entry: device info needs to either describe a device, link to existing device or provide extra information.

In which version of Home Assistant Core do you have the problem?
2023.8.0b1
What version of Proxmox VE Custom Integration has the issue?
2.0.4
What version of Proxmox VE do you have the problem?
8.0.3
Additional information
No response

Sorry, didn't notice there was a 2.0.4 update, so I wasn't on the last version. Updating to 2.0.4 and a restart seems to have resolved the issue.


fix: improve creation of react component

Avoid setting element property if already set as attribute.
Always set id as attribute to ensure id bindings

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

:exclamation: No coverage uploaded for pull request base (main@0cae556). Click here to learn what that means.

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
Additional details and impacted files
@@           Coverage Diff           @@
##             main    #2337   +/-   ##
=======================================
  Coverage        ?   93.61%
=======================================
  Files           ?      239
  Lines           ?    24388
  Branches        ?     2156
=======================================
  Hits            ?    22832
  Misses          ?     1513
  Partials        ?       43

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


Doc(eos_designs): Update custom_structured_config doc following merge changes in 4.0.0

Change Summary
Update documentation related to custom_structured_config feature following the change of the default merge strategy from replace to append_rp in v4.0.0
Related Issue(s)
Component(s) name
arista.avd.eos_designs
Proposed changes

Update examples and related notes

How to test
Use default append_rp merge strategy to confirm interaction between:

eos_designs's name_servers vs eos_cli_config_gen's ip_name_servers
eos_designs's ipv4_acls vs eos_cli_config_gen's ip_access_lists

Checklist
User Checklist

N/A

Repository Checklist

[ x] My code has been rebased from devel before I start
[ x] I have read the CONTRIBUTING document.
[ x] My change requires a change to the documentation and documentation have been updated accordingly.
[ x] I have updated molecule CI testing accordingly. (check the box if not applicable)

Please prioritize to get this PR ready if we need it in 5.0.


update(libsinsp): drop also untracked syscalls in kernel-side simple consumer mode

Signed-off-by: Andrea Terzolo<EMAIL_ADDRESS>What type of PR is this?
/kind feature
Any specific area of the project related to this PR?
/area libsinsp
What this PR does / why we need it:
Today, in the kernel-side simple consumer mode, all the events related to syscalls marked with the flag EF_DROP_SIMPLE_CONS are not pushed to the ringbuffer unless they are marked with the flag UF_NEVER_DROP. The idea here is to drop also all events related to untracked syscalls (PPM_SC_UNKNOWN enum) since they don't seem to particularly enrich the capture with useful information.
To do that, we could simply change the flag of the PPM_SC_UNKNOWN enum, from EF_NONE to EF_DROP_SIMPLE_CONS here. This however would lead to dropping these events also in userspace-side simple consumer mode and this behavior does not seem to be desired since the flag EF_DROP_SIMPLE_CONS was not set at the time. So to not alter the behavior, I suggest adding the right line directly in the for loop.
In my opinion, these events do not carry important information and therefore can be truncated together with the other events already neglected by the kernel-side simple consumer approach, but this is just my opinion, I am obviously open to suggestions.
Which issue(s) this PR fixes:
Fixes #
Special notes for your reviewer:
Does this PR introduce a user-facing change?:
None

Hi @Andreagit97. Thanks for your PR.
I'm waiting for a falcosecurity member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.
Once the patch is verified, the new status will be reflected by the ok-to-test label.
I understand the commands that are listed here.

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by: Andreagit97
To complete the pull request process, please assign gnosek after the PR has been reviewed.
You can assign the PR to them by writing /assign @gnosek in a comment when ready.
The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

Hi! This is a neat idea! +1 from me!
/ok-to-test

I'd like to know what do other people think about this one ;)
/cc @gnosek @mstemm

/test build-libs-arm

Hi folks! Do you have any feedback on this?

LGTM label has been added.  Git tree hash: 6e665804ed71c4d9d650f33997940a637dcb8d00

[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: Andreagit97, FedeDP
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

OWNERS [FedeDP]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment


Translation Delivery (DEV)

Translation Delivery

This pull request is for translation delivery. Please review and approve them,  @D067796

This pull request is for translation delivery. Please review and approve them,  @D067796


Added Module._load patch to collector

[skip ci]

@basti1302 what do you hink?
This is a small PoC / proposal to prevent sibling packages in the monorepo to require each other.
Of course, in this case the protection is specifically from the collector towards the core, but we can either replicate the change to other packages or think of something else to reuse the code.

IMO this can be solved by static analysis and should not require a check at runtime. I've put up #321 as an alternative, checking this with an eslint plugin.


Failed to download Valheim server from Steam

My Valheim docker was working but today it does not:
2022-07-29T15:35:17.489319236Z | stdout | Jul 29 15:35:17 /supervisord: valheim-updater [----] !!! Fatal Error: Steamcmd needs to be online to update.
The errors match issue #401
Has anyone else had this problem?

2022-07-29T15:35:29.087939894Z
stdout
2022-07-29 15:35:29,087 INFO reaped unknown pid 100 (exit status 0)

2022-07-29T15:35:28.086683631Z
stdout
Jul 29 15:35:28 assert_20220729153517_6.dmp[100]: file ''/tmp/dumps/assert_20220729153517_6.dmp'', upload no: ''Couldn't resolve host name''

2022-07-29T15:35:28.086642975Z
stdout
Jul 29 15:35:28 assert_20220729153517_6.dmp[100]: error: Couldn't resolve host name

2022-07-29T15:35:28.086346391Z
stdout
Jul 29 15:35:28 assert_20220729153517_6.dmp[100]: Finished uploading minidump (out-of-process): success = no

2022-07-29T15:35:18.007962128Z
stdout
Jul 29 15:35:18 /supervisord: valheim-updater ERROR - Failed to download Valheim server from Steam - retrying later - check your networking and volume access permissions

2022-07-29T15:35:18.006855932Z
stdout
Jul 29 15:35:18 /supervisord: valheim-updater src/tier0/threadtools.cpp (3628) : Assertion Failed: Illegal termination of worker thread 'Thread(0x0x57644f90/0x0xf6f3bb'

2022-07-29T15:35:18.003647720Z
stdout
Jul 29 15:35:18 assert_20220729153517_6.dmp[100]: Uploading dump (out-of-process) /tmp/dumps/assert_20220729153517_6.dmp

2022-07-29T15:35:17.489319236Z
stdout
Jul 29 15:35:17 /supervisord: valheim-updater [----] !!! Fatal Error: Steamcmd needs to be online to update. Please confirm your network connection and try again.

Don't worry it was a port problem. All up and running. Thanks :-)

I am getting the error again today. I'm running through docker on my Synology. All needed ports are open and I have set DNS. It seems not to be able to download the steam server. Has anyone got a few ideas to try?

2022-08-03T08:45:42.473474068Z
stdout
2022-08-03 08:45:42,473 INFO reaped unknown pid 346 (exit status 0)

2022-08-03T08:45:41.472222844Z
stdout
Aug  3 08:45:41 assert_20220803084531_6.dmp[346]: file ''/tmp/dumps/assert_20220803084531_6.dmp'', upload no: ''Couldn't resolve host name''

2022-08-03T08:45:41.472180116Z
stdout
Aug  3 08:45:41 assert_20220803084531_6.dmp[346]: error: Couldn't resolve host name

2022-08-03T08:45:41.471899619Z
stdout
Aug  3 08:45:41 assert_20220803084531_6.dmp[346]: Finished uploading minidump (out-of-process): success = no

2022-08-03T08:45:31.247019689Z
stdout
Aug  3 08:45:31 /supervisord: valheim-updater ERROR - Failed to download Valheim server from Steam - retrying later - check your networking and volume access permissions

2022-08-03T08:45:31.245818525Z
stdout
Aug  3 08:45:31 /supervisord: valheim-updater src/tier0/threadtools.cpp (3628) : Assertion Failed: Illegal termination of worker thread 'Thread(0x0x58743f90/0x0xf6edfb'

2022-08-03T08:45:31.243012929Z
stdout
Aug  3 08:45:31 assert_20220803084531_6.dmp[346]: Uploading dump (out-of-process) /tmp/dumps/assert_20220803084531_6.dmp

2022-08-03T08:45:31.211235326Z
stdout
Aug  3 08:45:31 /supervisord: valheim-updater [----] !!! Fatal Error: Steamcmd needs to be online to update. Please confirm your network connection and try again.

2022-08-03T08:45:31.211218635Z
stdout
Aug  3 08:45:31 /supervisord: valheim-updater [  0%] Checking for available updates...

2022-08-03T08:45:31.211201348Z
stdout
Aug  3 08:45:31 /supervisord: valheim-updater [  0%] Downloading update...

2022-08-03T08:45:31.211178225Z
stdout
Aug  3 08:45:31 /supervisord: valheim-updater [----] Verifying installation...

2022-08-03T08:45:31.211111182Z
stdout
Aug  3 08:45:31 /supervisord: valheim-updater [  0%] Checking for available updates...

2022-08-03T08:45:31.210798476Z
stdout
Aug  3 08:45:31 /supervisord: valheim-updater Redirecting stderr to '/home/valheim/Steam/logs/stderr.txt'

2022-08-03T08:45:09.328365575Z
stdout
Aug  3 08:45:09 /supervisord: valheim-updater INFO - Downloading/updating/validating Valheim server from Steam

Does seem to be a problem like - The errors match issue - https://github.com/lloesche/valheim-server-docker/issues/401

I'm seeing this issue on a Synology on DSM 7 with the latest build from 2 days ago via #504 update.

delete the old image and pulled down the latest and tried a fresh container with no config import and with config import
tried removing everything in the data directory
added steamcmd ports i found online, didn't help
double checked directory permissions. same as before

Did you get it to work? My docker container crashes DSM 7.

The debian10 release worked fine.
https://hub.docker.com/layers/lloesche/valheim-server/debian10/images/sha256-10144e853814fc227898387075b25aba8fb4f1d288c1640a837db25d4db016ce?context=explore

I am experiencing this issue on my ubuntu server. Fresh install completely. Ports should be opened correctly.

My docker container also crashes DSM 7 completely now and is failing at the steam update step
2022-12-10T23:00:40.484200663Z	stdout	Dec 10 23:00:40 supervisord: valheim-updater /opt/steamcmd/steamcmd.sh: line 39:    64 Segmentation fault      (core dumped) $DEBUGGER "$STEAMEXE" "$@" 2022-12-10T23:00:40.441502429Z	stdout	Dec 10 23:00:40 crash_20221210230040_9.dmp[75]: Uploading dump (out-of-process) /tmp/dumps/crash_20221210230040_9.dmp 2022-12-10T23:00:40.069960960Z	stdout	Dec 10 23:00:40 supervisord: valheim-updater src/tier0/threadtools.cpp (1804) : Thread synchronization object is unuseable 2022-12-10T23:00:39.919952562Z	stdout	Dec 10 23:00:39 supervisord: valheim-updater CWorkThreadPool::StartWorkThread: Thread creation failed. 2022-12-10T23:00:39.886181163Z	stdout	Dec 10 23:00:39 supervisord: valheim-updater Thread failed to initialize 2022-12-10T23:00:39.886113490Z	stdout	Dec 10 23:00:39 supervisord: valheim-updater src/tier0/threadtools.cpp (4122) : Probably deadlock or failure waiting for thread to initialize. 2022-12-10T23:00:39.885943007Z	stdout	Dec 10 23:00:39 supervisord: valheim-updater CWorkThreadPool::StartWorkThread: Thread creation failed. 2022-12-10T23:00:39.852519811Z	stdout	Dec 10 23:00:39 supervisord: valheim-bootstrap valheim-updater: started 2022-12-10T23:00:39.852470665Z	stdout	Dec 10 23:00:39 supervisord: valheim-updater Thread failed to initialize 2022-12-10T23:00:39.852296465Z	stdout	Dec 10 23:00:39 supervisord: valheim-updater src/tier0/threadtools.cpp (4122) : Probably deadlock or failure waiting for thread to initialize. 2022-12-10T23:00:39.849307522Z	stdout	Dec 10 23:00:39 supervisord: valheim-updater Thread failed to initialize 2022-12-10T23:00:39.849254932Z	stdout	Dec 10 23:00:39 supervisord: valheim-updater [  0%] Checking for available updates... 2022-12-10T23:00:39.849184248Z	stdout	Dec 10 23:00:39 supervisord: valheim-updater src/tier0/threadtools.cpp (4122) : Probably deadlock or failure waiting for thread to initialize. 2022-12-10T23:00:39.848890912Z	stdout	2022-12-10 23:00:39,848 INFO success: valheim-updater entered RUNNING state, process has stayed up for > than 1 seconds (startsecs) 2022-12-10T23:00:39.790462709Z	stdout	Dec 10 23:00:39 supervisord: valheim-updater Redirecting stderr to '/home/valheim/Steam/logs/stderr.txt' 2022-12-10T23:00:39.790308964Z	stdout	2022-12-10 23:00:39,789 INFO success: crond entered RUNNING state, process has stayed up for > than 1 seconds (startsecs) 2022-12-10T23:00:39.789691741Z	stdout	2022-12-10 23:00:39,789 INFO success: syslogd entered RUNNING state, process has stayed up for > than 1 seconds (startsecs) 2022-12-10T23:00:39.373079373Z	stdout	Dec 10 23:00:39 supervisord: valheim-updater INFO - Downloading/updating/validating Valheim server from Steam

The debian10 release worked fine.
hub.docker.com/layers/lloesche/valheim-server/debian10/images/sha256-10144e853814fc227898387075b25aba8fb4f1d288c1640a837db25d4db016ce?context=explore

My docker container was also crashing DSM 7 completely and failing at update step, this debian10 release fixed it for me too

Cool, I will give it a try.

I am experiencing the same "Failed to download Valheim server from Steam"
What was your solution to fix this? I can't figure out the port fix.
I've tried ports from container, to permissions on the nas, and router. I even tried opening ports to Steamcmd, and still no luck.
Any help is appreciated!

I'm also getting the same error "valheim-updater ERROR - Failed to download Valheim server from Steam - retrying later - check your networking and volume access permissions".
My specific setup uses Azure Container Instance mounting to an Azure Storage Account. The container has no trouble writing to the /config path, but using another share with the same storage account and the /opt/valheim path fails.
I am able to get it to function if instead I mount to /opt/valheim/server, but the consequence of this is that it re-downloads the entire game on every startup.
I also had the same experience with the debian10 release linked above.
Can anyone please suggest a fix for this?

I'm also getting the same error "valheim-updater ERROR - Failed to download Valheim server from Steam - retrying later - check your networking and volume access permissions". My specific setup uses Azure Container Instance mounting to an Azure Storage Account. The container has no trouble writing to the /config path, but using another share with the same storage account and the /opt/valheim path fails. I am able to get it to function if instead I mount to /opt/valheim/server, but the consequence of this is that it re-downloads the entire game on every startup. I also had the same experience with the debian10 release linked above. Can anyone please suggest a fix for this?

I have this same ERROR. When I deploy a fresh container the valheim server starts fine and can be connected to. If I decided to stop the container and start it again later. I get the above ERROR and am no longer able to connect to the server. The only consistent wha I have found to fix this is to redeploy the container and everything works fine. I just can never stop it.


Remove double H1 tag in your code!

Too busy with compiler issues, but you need to remove the double H1 in your own code. Bad practice!

I don't really mind.

Fixed it anyway.


Mega menus

Menus continue to be a complex challenge on each website build we do, especially those with mega menus. We should as a team work together to find a robust solution for building mega menus. Weather that is through full site editing, or simplifying the current menu walker approach whilst making it more flexible.
I do wonder if block template parts could be used some how in this approach, but again to be discussed.
Also partially related to #6

Solved in Pulsar Blocks with the mega menu block


Warn when using global Prisma CLI in project that has local Prisma dependency

We should warn the user when they are using a global Prisma CLI, although their project has a local prisma dependency as this can lead to confusion, especially if the versions do not match.
1 example: https://github.com/prisma/prisma/discussions/7189

Closing as duplicate of https://github.com/prisma/prisma/issues/2738