Hi there! I have just had the following installed, a BiDi wifi controller setup with the MyNice app (not mynice welcome or mynice pro)
Is there anyway I can automate this with homeassistant?
1 Like
Bidi WiFi with stock firmware can’t connect to Home Asisstant.
But hardware is ESP32 and we can use any custom firmware.
I have beta version ESPhome component for bust4 protocol (for esp32).
Its not stable but works.
2 Likes
Hello Pruwait, to program the esp32wroom on the bidiwifi, must it be desoldered!
You say your program is not stable what are the problems?
Thank you in advance, I would like to try to modify my bidiwifi on a Nice portal.
Is it possible to have new of this ?
Can we have the position opening ?
Hello,
a few weeks ago I completed your circuit, and it works with the Nice FILO400 as well. I also disassembled the BiDiWifit, and I will use it for this purpose, although the ESP8266 version worked too. The only issue was that the PCB board you made is too tall, so I couldn’t screw the cover back on and had to extend it with cables to the connector. Otherwise, everything worked on the first try. I set up the script in ESPHOME for the sliding gate.
Once a week my RD500HS not answering for a command. Remote control and Bus T4 commands not working. After rebooting RD500HS thats OK. I think that BIDI hardware Wifi use gpio 16 gpio 17 (UART2) for flashing and update RS500HS firmware. Perhaps my esphome component need use UART2 too. Need more tests.
1 Like
The new version my adapter is smaller.
2 Likes
Hi,
That’s good news. I looked at the pictures, and it looks really good, much smaller indeed.
I solved the problem by extending the wires, as there is plenty of space in the enclosure.
do you have the gerber files for your net board or an updated version of your ESPHome component for the ESP32?
just recently got a “Nice FILO400” installed and wanted to bring it into home assistant with either of the boards
any help would be appreciated thanks
hey,
was there anything special you needed to change in the esphome yaml for get this to work with the nice FILO400 board?
been trying for a couple of day with just using a wemos d1 mini and a logic level shifter and have gotten nowhere
Hello, it’s likely the new OTA configuration of ESPHome is causing the problem, see this link.
That is, the OTA section should look like this:
ota:
- platform: esphome
I’ll send the working nice_yaml file from home later, because I made some changes compared to the original. In fact, if I see correctly, the current nice yaml already includes this change, and its content has been completely renewed as well.
Well, this is the YAML I’m using in the current control setup:
# Vezérlő csomagokat küld UART-on keresztül a Nice BUS T4-nek
# Teszt áramkör: ESP-12E
#
# 1. teszt: 2024.03.13 - apró javítások
# 2. teszt: 2024.03.19 - hibátlan!
substitutions:
device_name: "nice-bust4-uart"
esphome:
name: ${device_name}
platform: ESP8266
board: esp12e
external_components:
- source:
type: git
url: https://github.com/pruwait/Nice_BusT4
# Engedélyezzük a hibakeresést, hogy megtaláljuk az újraindítás okát a naplóban
debug:
# Naplózás engedélyezése
logger:
level: DEBUG
# level: VERBOSE
baud_rate: 0
# Home Assistant API engedélyezése
api:
reboot_timeout: 0s # Egyébként újraindul, ha leválasztják a hassio-ról
services:
# Hexadecimális parancsok küldése
- service: raw_command
variables:
raw_cmd: string
then:
lambda: |-
my_nice_cover -> NiceBusT4::send_raw_cmd(raw_cmd);
- service: send_inf_command
variables:
to_addr: string
whose: string
command: string
type_command: string
next_data: string
data_on: bool
data_command: string
then:
lambda: |-
my_nice_cover -> NiceBusT4::send_inf_cmd(to_addr, whose, command, type_command, next_data, data_on, data_command);
# Kapuhossz felismerés
- service: gate_length_recognition
then:
lambda: |-
my_nice_cover -> NiceBusT4::set_mcu("0b","01");
# BlueBus eszköz felismerés
- service: devices_recognition
then:
lambda: |-
my_nice_cover -> NiceBusT4::set_mcu("0a","01");
# std::vector < uint8_t > v_to_addr = my_nice_cover -> NiceBusT4::raw_cmd_prepare (to_addr);
# std::vector < uint8_t > v_whose = my_nice_cover -> NiceBusT4::raw_cmd_prepare (whose);
# std::vector < uint8_t > v_command = my_nice_cover -> NiceBusT4::raw_cmd_prepare (command);
# std::vector < uint8_t > v_type_command = my_nice_cover -> NiceBusT4::raw_cmd_prepare (type_command);
# std::vector < uint8_t > v_data_command = my_nice_cover -> NiceBusT4::raw_cmd_prepare (data_command);
# if (data_on) {
# my_nice_cover -> NiceBusT4::tx_buffer_.push(my_nice_cover -> NiceBusT4::gen_inf_cmd(v_to_addr[0], v_to_addr[1], v_whose[0], v_command[0], v_type_command[0], v_data_command, v_data_command.size()));
# } else {
# my_nice_cover -> NiceBusT4::tx_buffer_.push(my_nice_cover -> NiceBusT4::gen_inf_cmd(v_to_addr[0], v_to_addr[1], v_whose[0], v_command[0], v_type_command[0]));
# }
ota:
- platform: esphome
# Beállítja az ESP-12E állapotjelző LED-jét
status_led:
pin:
number: GPIO5
inverted: true
wifi:
ssid: !secret wifi_ssid
password: !secret wifi_password
power_save_mode: HIGH
fast_connect: true # Rejtett SSID miatt
# Engedélyezzük a tartalék hotspotot (captive portal) arra az esetre, ha a wifi kapcsolattal probléma lenne
ap:
ssid: "${device_name} Hotspot"
password: !secret appw
captive_portal:
# Webszerver engedélyezése (letiltható)
web_server:
port: 80
# Parancsok küldésére szolgáló gombok a HA-ban
button:
- platform: template
name: Lépésről lépésre
id: sbs
on_press:
lambda: |-
my_nice_cover -> NiceBusT4::send_cmd(bus_t4::SBS);
# my_nice_cover -> NiceBusT4::send_raw_cmd("55 0c 00 ff 00 66 01 05 9D 01 82 01 64 E6 0c"); # Közvetlen parancs
- platform: template
name: Részleges nyitás 1
id: p_opn1
on_press:
lambda: |-
my_nice_cover -> NiceBusT4::send_cmd(bus_t4::P_OPN1);
# my_nice_cover -> NiceBusT4::send_cmd(bus_t4::STOP);
# my_nice_cover -> NiceBusT4::send_cmd(bus_t4::OPEN);
# my_nice_cover -> NiceBusT4::send_cmd(bus_t4::CLOSE);
# my_nice_cover -> NiceBusT4::send_cmd(bus_t4::P_OPN2);
# my_nice_cover -> NiceBusT4::send_cmd(bus_t4::P_OPN3);
# my_nice_cover -> NiceBusT4::send_cmd(bus_t4::P_OPN4);
# my_nice_cover -> NiceBusT4::send_cmd(bus_t4::P_OPN5);
# my_nice_cover -> NiceBusT4::send_cmd(bus_t4::P_OPN6);
# my_nice_cover -> NiceBusT4::send_cmd(bus_t4::UNLK_OPN); # Разблокировать и открыть
# my_nice_cover -> NiceBusT4::send_cmd(bus_t4::CLS_LOCK); # Закрыть и блокировать
# my_nice_cover -> NiceBusT4::send_cmd(bus_t4::UNLCK_CLS); # Разблокировать и Закрыть
# my_nice_cover -> NiceBusT4::send_cmd(bus_t4::LOCK); # Блокировать
# my_nice_cover -> NiceBusT4::send_cmd(bus_t4::UNLOCK); # Разблокировать
# my_nice_cover -> NiceBusT4::send_cmd(bus_t4::HOST_SBS); # Ведущий SBS
# my_nice_cover -> NiceBusT4::send_cmd(bus_t4::HOST_OPN); # Ведущий открыть
# my_nice_cover -> NiceBusT4::send_cmd(bus_t4::HOST_CLS); # Ведущий закрыть
# my_nice_cover -> NiceBusT4::send_cmd(bus_t4::SLAVE_SBS); # Ведомый SBS
# my_nice_cover -> NiceBusT4::send_cmd(bus_t4::SLAVE_OPN); # Ведомый открыть
# my_nice_cover -> NiceBusT4::send_cmd(bus_t4::SLAVE_CLS); # Ведомый закрыть
# my_nice_cover -> NiceBusT4::send_cmd(bus_t4::AUTO_ON); # Автооткрывание активно
# my_nice_cover -> NiceBusT4::send_cmd(bus_t4::AUTO_OFF); # Автооткрывание неактивно
cover:
- platform: bus_t4
name: "Nice FILO400"
id: my_nice_cover
device_class: gate
I apologize for the mixed language, but the main point is clear:
The changes can essentially be seen in two places: around the middle in the OTA section and at the very end in the last COVER section.
In the attached image, everything appears inactive, but it shows up on the interface like this and it works.
Couldn’t get this to work in the end even after trying for a while this is the controller board I have in mine
I ended up using a spare remote and a relay board with an esp32 and controlling it that way
I have a Nice CL101R10 control module:
By the way, I’ve noticed a difference between the two control modules. Additionally, the new YAML utilizes a different code compared to the old one. I still have the previous version in the ESP12F, but I plan to test it with the updated one when I have time.
thank you very much!
But when i would install the esp 32 wroom, I have somes errors
src/esphome/components/bus_t4/nice-bust4.h:65:27: error: 'UART0' was not declared in this scope
static const int _UART_NO=UART0; /* номер uart */
^~~~~
src/esphome/components/bus_t4/nice-bust4.h:65:27: note: suggested alternative: 'UART_ID'
static const int _UART_NO=UART0; /* номер uart */
^~~~~
UART_ID
src/esphome/components/bus_t4/nice-bust4.cpp: In member function 'virtual void esphome::bus_t4::NiceBusT4::setup()':
src/esphome/components/bus_t4/nice-bust4.cpp:74:55: error: 'SERIAL_FULL' was not declared in this scope
_uart = uart_init(_UART_NO, BAUD_WORK, SERIAL_8N1, SERIAL_FULL, TX_P, 256, false);
^~~~~~~~~~~
src/esphome/components/bus_t4/nice-bust4.cpp:74:55: note: suggested alternative: 'SERIAL_5E1'
_uart = uart_init(_UART_NO, BAUD_WORK, SERIAL_8N1, SERIAL_FULL, TX_P, 256, false);
^~~~~~~~~~~
SERIAL_5E1
src/esphome/components/bus_t4/nice-bust4.cpp:74:12: error: 'uart_init' was not declared in this scope
_uart = uart_init(_UART_NO, BAUD_WORK, SERIAL_8N1, SERIAL_FULL, TX_P, 256, false);
^~~~~~~~~
src/esphome/components/bus_t4/nice-bust4.cpp:74:12: note: suggested alternative: 'arch_init'
_uart = uart_init(_UART_NO, BAUD_WORK, SERIAL_8N1, SERIAL_FULL, TX_P, 256, false);
^~~~~~~~~
arch_init
src/esphome/components/bus_t4/nice-bust4.cpp: In member function 'virtual void esphome::bus_t4::NiceBusT4::loop()':
src/esphome/components/bus_t4/nice-bust4.cpp:114:10: error: 'uart_rx_available' was not declared in this scope
while (uart_rx_available(_uart) > 0) {
^~~~~~~~~~~~~~~~~
src/esphome/components/bus_t4/nice-bust4.cpp:114:10: note: suggested alternative: 'uartAvailable'
while (uart_rx_available(_uart) > 0) {
^~~~~~~~~~~~~~~~~
uartAvailable
src/esphome/components/bus_t4/nice-bust4.cpp:115:26: error: 'uart_read_char' was not declared in this scope
uint8_t c = (uint8_t)uart_read_char(_uart); // считываем байт
^~~~~~~~~~~~~~
src/esphome/components/bus_t4/nice-bust4.cpp:115:26: note: suggested alternative: 'uartRead'
uint8_t c = (uint8_t)uart_read_char(_uart); // считываем байт
^~~~~~~~~~~~~~
uartRead
src/esphome/components/bus_t4/nice-bust4.cpp: In member function 'void esphome::bus_t4::NiceBusT4::send_array_cmd(const uint8_t*, size_t)':
src/esphome/components/bus_t4/nice-bust4.cpp:939:3: error: 'uart_flush' was not declared in this scope
uart_flush(_uart); // очищаем uart
^~~~~~~~~~
src/esphome/components/bus_t4/nice-bust4.cpp:939:3: note: suggested alternative: 'uartFlush'
uart_flush(_uart); // очищаем uart
^~~~~~~~~~
uartFlush
src/esphome/components/bus_t4/nice-bust4.cpp:940:3: error: 'uart_set_baudrate' was not declared in this scope
uart_set_baudrate(_uart, BAUD_BREAK); // занижаем бодрэйт
^~~~~~~~~~~~~~~~~
src/esphome/components/bus_t4/nice-bust4.cpp:940:3: note: suggested alternative: 'uartGetBaudRate'
uart_set_baudrate(_uart, BAUD_BREAK); // занижаем бодрэйт
^~~~~~~~~~~~~~~~~
uartGetBaudRate
src/esphome/components/bus_t4/nice-bust4.cpp:941:3: error: 'uart_write' was not declared in this scope
uart_write(_uart, &br_ch, 1); // отправляем ноль на низкой скорости, длиинный ноль
^~~~~~~~~~
src/esphome/components/bus_t4/nice-bust4.cpp:941:3: note: suggested alternative: 'uartWrite'
uart_write(_uart, &br_ch, 1); // отправляем ноль на низкой скорости, длиинный ноль
^~~~~~~~~~
uartWrite
src/esphome/components/bus_t4/nice-bust4.cpp:943:3: error: 'uart_wait_tx_empty' was not declared in this scope
uart_wait_tx_empty(_uart); // ждём, пока отправка завершится. Здесь в библиотеке uart.h (esp8266 core 3.0.2) ошибка, ожидания недостаточно при дальнейшем uart_set_baudrate().
Do you know what could be the problem?
Although I don’t think you were asking me, here’s what I think:
Based on the error messages gathered by ESPHome, the following conclusions can be drawn:
Undeclared variables and functions:
It often occurs that certain variables (e.g., UART0, SERIAL_FULL) and functions (e.g., uart_init, uart_rx_available, uart_read_char) are not declared. This suggests that the definitions used in the current code are either not available or do not exist in the ESP32 environment.
Alternative suggestions:
The error messages suggest alternative definitions, such as UART_ID, SERIAL_5E1, arch_init, etc. These alternatives indicate that the functions should likely be called with different names or parameters in the ESP32 environment.
Code compatibility:
The source code was likely originally made for the ESP8266, and it does not work properly in the ESP32 environment because the ESP8266-specific functions and definitions are not available in the ESP32. Due to the hardware and software differences between the ESP32 and ESP8266, the code may need to be reworked or alternative libraries used.
Solution suggestions: Find the appropriate functions and definitions for the ESP32:
Check if there is an appropriate library or definition for the functions used for the ESP32. For example, instead of uart_rx_available, you might need to use uartAvailable.
I would first try with the ESP8266, and if it works on that, then I would switch to the ESP32.
Thanks a lot, I thought esp 32 and esp 8266 used the same functions. I will try to modify the code for esp32
Any luck here with BiDi WiFi? I have Nice Robus 600 with ROA41 controller.
I ended up forking pruwait’s ESPHome component and rewriting a bunch of stuff to support ESP32. I also made it possible to optionally define custom UART and TX/RX pins in yaml, with uart_num, tx_pin, and rx_pin options.
But so far, I haven’t managed to find the pins that are used for UART on BiDi WiFi. At least, default UART0 and UART2 pins don’t seem to do much. At least, with UART2, the same packet that is sent - is then received in response.
[15:08:18][D][bus_t4.cover:1010]: Sent packet: 55.0D.00.FF.00.66.08.06.97.00.04.99.00.00.9D.0D (16)
[15:08:18][D][bus_t4.cover:265]: Received packet: 55.0D.00.FF.00.66.08.06.97.00.04.99.00.00.9D.0D (16)
[15:08:18][D][bus_t4.cover:1010]: Sent packet: 55.0D.00.FF.00.66.08.06.97.00.09.99.00.00.90.0D (16)
[15:08:18][D][bus_t4.cover:265]: Received packet: 55.0D.00.FF.00.66.08.06.97.00.09.99.00.00.90.0D (16)
Hi! I kept the old controller, I haven’t had much time lately. But now that I see your solution, I’ll give it a try in a few weeks.
A note about the wiring diagram: I redesigned mine and use the level-shifter.png solution everywhere, even instead of the BAT54A diode. Additionally, I have double transistors and resistor ladders on the board.
I’m also considering adding a temperature sensor to the board, so if the temperature gets too low, it will activate the heating element under the sliding gate rail to prevent freezing (this would only require two extra components). There was also an idea I later abandoned, to directly generate 3.3V from 24…30V, skipping the LPO 5V regulator, thus saving some components.
I’m cautious with the gate electronics, so I don’t dare to experiment too much - I prefer making small, logical modifications.
But first, I’ll build your solution and see how it works. If everything is fine with the Nice Filo400 too, I’ll continue in that direction.
(To be honest, I use the ESP12F for everything because I bought a lot of them in the past, and I still have about 15 pieces. I only have one ESP32, so it seemed logical to go for the simpler solution. The system won’t gain much with the ESP32, but it’s true that in the future, its capabilities, like Bluetooth, could be better utilized.)
Hi everyone,
I’ve been working for a few days now to get full functionality with a Nice SNA4/A garage opener. So far, I’ve only managed to send RAW commands successfully - Open, Stop, Close, and SBS raw commands work. However, I can’t seem to retrieve the status of the garage opener.
The SNA4/A model has an RJ11 connector, and I’ve used the exact schematic provided by @pruwait. When the ESP polls the devices connected to the BusT4 bus at boot, I get a “Type: Unknown gate, 0x55” message, and the remaining outputs are blank.
Has anyone encountered this issue or have any ideas on how to get the current status of the gate?
Thanks in advance!