install on WT32-ETH01 device

[leranp]

In the beginning i used ESP32-CAM device and i worked fine for more than 1 month , but now i bought a WT32-ETH01 device and i have an errors when install, it can work on the device but i have a reboots when the lock\unlock is triggered.

this is the logs from the installation

In file included from src/esphome/components/nuki_lock/nuki_lock.cpp:1:0:
src/esphome/components/nuki_lock/nuki_lock.h: In member function 'virtual void esphome::nuki_lock::Handler::notify(Nuki::EventType)':
src/esphome/core/log.h:105:99: warning: format '%d' expects argument of type 'int', but argument 5 has type 'Nuki::EventType' [-Wformat=]
   esp_log_printf_(ESPHOME_LOG_LEVEL_INFO, tag, __LINE__, ESPHOME_LOG_FORMAT(format), ##__VA_ARGS__)
                                                                                                   ^
src/esphome/core/log.h:150:28: note: in expansion of macro 'esph_log_i'
 #define ESP_LOGI(tag, ...) esph_log_i(tag, __VA_ARGS__)
                            ^
src/esphome/components/nuki_lock/nuki_lock.h:22:9: note: in expansion of macro 'ESP_LOGI'
         ESP_LOGI(TAG, "event notified %d", eventType);      
         ^
src/esphome/components/nuki_lock/nuki_lock.cpp: In member function 'void esphome::nuki_lock::NukiLock::update_status()':
src/esphome/core/log.h:105:99: warning: format '%d' expects argument of type 'int', but argument 8 has type 'Nuki::LockState' [-Wformat=]
   esp_log_printf_(ESPHOME_LOG_LEVEL_INFO, tag, __LINE__, ESPHOME_LOG_FORMAT(format), ##__VA_ARGS__)
                                                                                                   ^
src/esphome/core/log.h:150:28: note: in expansion of macro 'esph_log_i'
 #define ESP_LOGI(tag, ...) esph_log_i(tag, __VA_ARGS__)
                            ^
src/esphome/components/nuki_lock/nuki_lock.cpp:29:9: note: in expansion of macro 'ESP_LOGI'
         ESP_LOGI(TAG, "Bat state: %#x, Bat crit: %d, Bat perc:%d lock state: %d %d:%d:%d",
         ^
src/esphome/components/nuki_lock/nuki_lock.cpp: In member function 'virtual void esphome::nuki_lock::NukiLock::setup()':
src/esphome/core/log.h:105:99: warning: format '%s' expects argument of type 'char*', but argument 5 has type 'const string* {aka const std::__cxx11::basic_string<char>*}' [-Wformat=]
   esp_log_printf_(ESPHOME_LOG_LEVEL_INFO, tag, __LINE__, ESPHOME_LOG_FORMAT(format), ##__VA_ARGS__)
                                                                                                   ^
src/esphome/core/log.h:150:28: note: in expansion of macro 'esph_log_i'
 #define ESP_LOGI(tag, ...) esph_log_i(tag, __VA_ARGS__)
                            ^
src/esphome/components/nuki_lock/nuki_lock.cpp:63:9: note: in expansion of macro 'ESP_LOGI'
         ESP_LOGI(TAG, "%s Nuki paired", this->deviceName_); 
         ^
src/esphome/core/log.h:114:99: warning: format '%s' expects argument of type 'char*', but argument 5 has type 'const string* {aka const std::__cxx11::basic_string<char>*}' [-Wformat=]
   esp_log_printf_(ESPHOME_LOG_LEVEL_WARN, tag, __LINE__, ESPHOME_LOG_FORMAT(format), ##__VA_ARGS__)
                                                                                                   ^
src/esphome/core/log.h:148:28: note: in expansion of macro 'esph_log_w'
 #define ESP_LOGW(tag, ...) esph_log_w(tag, __VA_ARGS__)
                            ^
src/esphome/components/nuki_lock/nuki_lock.cpp:68:9: note: in expansion of macro 'ESP_LOGW'
         ESP_LOGW(TAG, "%s Nuki is not paired", this->deviceName_); 
         ^

In file included from src/esphome/components/sensor/sensor.h:3:0,
                 from src/esphome/core/application.h:16,
                 from src/esphome/components/api/api_connection.h:4,
                 from src/esphome.h:3,
                 from src/main.cpp:3:
src/esphome/components/nuki_lock/nuki_lock.h: In member function 'virtual void esphome::nuki_lock::Handler::notify(Nuki::EventType)':
src/esphome/core/log.h:105:99: warning: format '%d' expects argument of type 'int', but argument 5 has type 'Nuki::EventType' [-Wformat=]
   esp_log_printf_(ESPHOME_LOG_LEVEL_INFO, tag, __LINE__, ESPHOME_LOG_FORMAT(format), ##__VA_ARGS__)
                                                                                                   ^
src/esphome/core/log.h:150:28: note: in expansion of macro 'esph_log_i'
 #define ESP_LOGI(tag, ...) esph_log_i(tag, __VA_ARGS__)
                            ^
src/esphome/components/nuki_lock/nuki_lock.h:22:9: note: in expansion of macro 'ESP_LOGI'
         ESP_LOGI(TAG, "event notified %d", eventType);      
         ^
Compiling .pioenvs/esp-lan/lib2ba/ESP32 BLE Arduino/BLEBeacon.cpp.o
Compiling .pioenvs/esp-lan/lib2ba/ESP32 BLE Arduino/BLECharacteristic.cpp.o
Compiling .pioenvs/esp-lan/lib2ba/ESP32 BLE Arduino/BLECharacteristicMap.cpp.o
Compiling .pioenvs/esp-lan/lib2ba/ESP32 BLE Arduino/BLEClient.cpp.o
.piolibdeps/esp-lan/ESP32 BLE Arduino/src/BLECharacteristic.cpp: In member function 'void BLECharacteristic::setValue(float&)':
.piolibdeps/esp-lan/ESP32 BLE Arduino/src/BLECharacteristic.cpp:680:16: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing]
  *((float*)temp) = data32;
                ^
.piolibdeps/esp-lan/ESP32 BLE Arduino/src/BLECharacteristic.cpp: In member function 'void BLECharacteristic::setValue(double&)':
.piolibdeps/esp-lan/ESP32 BLE Arduino/src/BLECharacteristic.cpp:686:17: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing]
  *((double*)temp) = data64;
                 ^
.piolibdeps/esp-lan/Nuki Ble for Esp32/src/NukiBle.cpp: In member function 'Nuki::PairingState Nuki::NukiBle::pairStateMachine(Nuki::PairingState)':
.piolibdeps/esp-lan/Nuki Ble for Esp32/src/NukiBle.cpp:1327:78: warning: ignoring return value of 'int crypto_scalarmult_curve25519(unsigned char*, const unsigned char*, const unsigned char*)', declared with attribute warn_unused_result [-Wunused-result]
       crypto_scalarmult_curve25519(sharedKeyS, myPrivateKey, remotePublicKey);
                                                                              ^
/config/.esphome/platformio/packages/framework-arduinoespressif32/cores/esp32/esp32-hal-i2c.c: In function 'i2cDumpFifo':
/config/.esphome/platformio/packages/framework-arduinoespressif32/cores/esp32/esp32-hal-i2c.c:415:35: warning: ' ' flag used with '%X' gnu_printf format [-Wformat=]
       } else k += sprintf(&buf[k],"% 4X ",fifoBuffer[i]);
                                   ^
/config/.esphome/platformio/packages/framework-arduinoespressif32/cores/esp32/esp32-hal-i2c.c:415:35: warning: ' ' flag used with '%X' gnu_printf format [-Wformat=]

/config/.esphome/platformio/packages/framework-arduinoespressif32/cores/esp32/esp32-hal-spi.c: In function 'spiTransferBytesNL':
/config/.esphome/platformio/packages/framework-arduinoespressif32/cores/esp32/esp32-hal-spi.c:922:39: warning: initialization from incompatible pointer type [-Wincompatible-pointer-types]
                 uint8_t * last_out8 = &result[c_longs-1];
                                       ^
/config/.esphome/platformio/packages/framework-arduinoespressif32/cores/esp32/esp32-hal-spi.c:923:40: warning: initialization from incompatible pointer type [-Wincompatible-pointer-types]
                 uint8_t * last_data8 = &last_data;
                                        ^

logs when lock is trigger:

[17:35:58][VV][scheduler:196]: Running interval 'update' with interval=500 last_execution=105832 (now=106336)
[17:35:58][VV][scheduler:196]: Running interval 'update' with interval=500 last_execution=106332 (now=106832)
[17:35:58][VV][scheduler:196]: Running interval 'update' with interval=60000 last_execution=46889 (now=106889)
[17:35:58][V][sensor:074]: 'Uptime EspLAN32 Sensor Sec': Received new state 106.890999
[17:35:58][D][sensor:125]: 'Uptime EspLAN32 Sensor Sec': Sending state 106.89100 s with 0 decimals of accuracy
[17:35:58][VV][api.service:140]: send_sensor_state_response: SensorStateResponse {
  key: XXXXXX
  state: 106.891
  missing_state: NO
}
[17:35:58][VV][api.service:570]: on_lock_command_request: LockCommandRequest {
  key: XXXXX
  command: LOCK_UNLOCK
  has_code: NO
  code: ''
}
INFO 192.168.XX.XX: Error while reading incoming messages: Error while reading data: [Errno 104] Connection reset by peer
INFO Disconnected from ESPHome API for 192.168.XX.XX
WARNING Disconnected from API
INFO 192.168.XX.XX: Ping Failed: Error while reading data: [Errno 104] Connection reset by peer
INFO Successfully connected to 192.168.XX.XX
[17:36:11][VV][scheduler:196]: Running interval 'update' with interval=500 last_execution=6908 (now=7408)

[uriyacovy]

Was the pairing with smart lock successful? Can you post your yaml and a screenshot of the esphome WT32-ETH01 device?

[leranp]

Was the pairing with smart lock successful? Can you post your yaml and a screenshot of the esphome WT32-ETH01 device?

The pairing is o.k, it works fine in standby, but most of the times when the nuki is changing state the esphome is restarting. This is the configuration:

esphome:
  name: esp-lan
  platform: ESP32
  board: esp-wrover-kit
  libraries:
  - Preferences
  - https://github.com/nkolban/ESP32_BLE_Arduino/
  - https://github.com/I-Connect/NukiBleEsp32#v0.0.4

ethernet:
  type: LAN8720
  mdc_pin: GPIO23
  mdio_pin: GPIO18
  clk_mode: GPIO0_IN
  phy_addr: 1
  power_pin: GPIO16
  use_address: 192.168.XX.XX

# Enable Home Assistant API
api:
  password: 'XXXXX'

logger:
  #level: VERY_VERBOSE

ota:
  password: 'XXXX'

sensor:
  - platform: uptime
    name: "Uptime EspLAN32 Sensor Sec"
    id: uptime_sec
    update_interval: 60s

external_components:
  - source: github://uriyacovy/ESPHome_nuki_lock

lock:
  - platform: nuki_lock
    name: Nuki Lock Bridge
    is_paired: 
      name: "Nuki Paired"
    battery_critical:
      name: "Nuki Battery Critical"
    battery_level:
      name: "Nuki Battery Level"

binary_sensor:
  - platform: gpio
    pin:
      number: GPIO03
      mode: INPUT_PULLUP
     # inverted: True
    name: "Door Open sensor"
    filters:
       - delayed_on_off: 50ms
    device_class: door

switch:
  - platform: gpio
    pin: GPIO14
    id: relay
    name: "Lobby Light"
    on_turn_on:
    - delay: 500ms
    - switch.turn_off: relay

[uriyacovy]

Thanks leranp. Since I don't have this type of board, and to try to minimize the debugging scope, can you disable the Ethernet, door sensor and light, and check how does it behave?

[leranp]

Thanks leranp. Since I don't have this type of board, and to try to minimize the debugging scope, can you disable the Ethernet, door sensor and light, and check how does it behave?

i tried to compile without the ethernet and the sensor and switch , but the errors are the same, my esphome version is 2022.6.2 if you compile with the same configuration the errors are still there? maybe there is something changed in one of the repositorys?

[leranp]

NimBLE-Arduino was changed 16 days ago , NukiBleEsp32 is install the newest version of NimBLE-Arduino and not the stable one

[uriyacovy]

NukiBleEsp32 points to v0.0.4 in your yaml, but in any case, I changed some time ago the yaml in the readme.md to point to my own fork. Can you try with:

  libraries:
  - Preferences
  - https://github.com/nkolban/ESP32_BLE_Arduino/
  - https://github.com/uriyacovy/NukiBleEsp32

[leranp]

NukiBleEsp32 points to v0.0.4 in your yaml, but in any case, I changed some time ago the yaml in the readme.md to point to my own fork. Can you try with:

  libraries:
  - Preferences
  - https://github.com/nkolban/ESP32_BLE_Arduino/
  - https://github.com/uriyacovy/NukiBleEsp32

Thank you, tried with your fork without the sensor and switch, but with the Ethernet component , I still have the same errors when compile the bin file ( clean all the files before ), I will give it a try to see if its now stable.

[uriyacovy]

Good, let me know if it's more stable.

[leranp]

Good, let me know if it's more stable.

after 1 day I can confirm that nothing was change, in the night it was stable because no one opened the door, but in the morning the door was open about 4 times , and 2 of them make the esphome to restart. the only option is to remove the Ethernet and switch to WIFI , but it is a bad option because I bought the device to be more stable and reliable in the network. will update if the Ethernet was the problem

[uriyacovy]

Sorry to hear that. I rebuilt the project from scratch with the latest HA and ESPHome on ESP32 wroom and it's running stable for several open and lock cycles. Looking forward to hear if the problem is related to the Ethernet.

[leranp]

Sorry to hear that. I rebuilt the project from scratch with the latest HA and ESPHome on ESP32 wroom and it's running stable for several open and lock cycles. Looking forward to hear if the problem is related to the Ethernet.

Same Problem, device restarting when the nuki changes the status Going to test it with the old device Esp32-cam, i suspect that something changed in one of the repositories versions. I will try to restart my nuki, maybe it's related to the problem

[leranp]

Sorry to hear that. I rebuilt the project from scratch with the latest HA and ESPHome on ESP32 wroom and it's running stable for several open and lock cycles. Looking forward to hear if the problem is related to the Ethernet.

Same Problem, device restarting when the nuki changes the status Going to test it with the old device Esp32-cam, i suspect that something changed in one of the repositories versions. I will try to restart my nuki, maybe it's related to the problem

After 1 day with this device nodemcu-32s, it was very stable compared to the Ethernet device, but i still had a one restart over the 24H when status changed , it is more reliable for me, i also remove the Nuki battery for 20 minutes to make a hard restart to the device and then test with the nodemcu-32s device for 1 day. It looks like something in the code doesn't catch the error if there's a wrong behavior and force the device to restart. Do you want me to change the log level to pull the logs when it happens?

[uriyacovy]

Glad to hear you made some progress. Sure, please send the logs.

[leranp]

Glad to hear you made some progress. Sure, please send the logs.

After 3 days i had only 1 restart, I think that the Ethernet device is defective when using the Bluetooth option, because it's stable without using it. So I am closing this issue and ordering a new Ethernet device Thanks for your help

[uriyacovy]

OK. Please update when the new Ethernet device arrives.