Closed znerk13 closed 2 years ago
Since I don't have any senseair sensor I can't test. Looking at the specification the K30 seems to use the same protocol as a S8 so yes it should just work.
Since senesair actually uses RS-485 / Modbus it should be possible to read the data using the modbus_controller
component
Can you try this config ?
uart:
id: mod_uart
tx_pin: 1
rx_pin: 3
baud_rate: 9600
stop_bits: 1
parity: none
modbus:
send_wait_time: 200ms
uart_id: mod_uart
id: mod_bus
modbus_controller:
- id: sensek30
## the Modbus device addr
address: 0xFE
modbus_id: mod_bus
command_throttle: 500ms
setup_priority: -10
update_interval: 30s
sensor:
- platform: modbus_controller
modbus_controller_id: sensek30
name: "K30 Co2 Status"
address: 0
register_type: "holding"
value_type: U_WORD
accuracy_decimals: 0
- platform: modbus_controller
modbus_controller_id: sensek30
id: co2
name: "K30 Co2 Level"
address: 3
unit_of_measurement: "ppm"
register_type: "holding"
value_type: U_WORD
accuracy_decimals: 0
Thanks for the fajst response!
I tested the code, but receive the following error message:
[13:33:35][D][modbus_controller.sensor:025]: Sensor new state: 0.00 [13:33:35][D][sensor:113]: 'K30 Co2 Status': Sending state 0.00000 with 0 decimals of accuracy [13:33:36][D][modbus:105]: Modbus error function code: 0x83 exception: 2 [13:33:36][E][modbus_controller:061]: Modbus error function code: 0x3 exception: 2 [13:33:36][E][modbus_controller:070]: Modbus error - last command: function code=0x3 register adddress = 0x3 registers count=1 payload size=0
Seems that I misread the documentation for the K30. Changing register type from `holding' to 'read' should fix the error
Did you close because the modbus approach works, or because you found another solution ?
Thank you! Now it works and it is running stable since 3 hours.
This is the final code I am running:
uart:
id: mod_uart
tx_pin: 15
rx_pin: 13
baud_rate: 9600
stop_bits: 1
parity: none
modbus:
send_wait_time: 200ms
uart_id: mod_uart
id: mod_bus
modbus_controller:
- id: sensek30
## the Modbus device addr
address: 0xFE
modbus_id: mod_bus
command_throttle: 500ms
setup_priority: -10
update_interval: 30s
sensor:
- platform: modbus_controller
modbus_controller_id: sensek30
name: "K30 CO2 Status"
address: 0
register_type: "read"
value_type: U_WORD
accuracy_decimals: 0
- platform: modbus_controller
modbus_controller_id: sensek30
id: co2
name: "K30 CO2 Level"
address: 3
unit_of_measurement: "ppm"
register_type: "read"
value_type: U_WORD
accuracy_decimals: 0
Nice thanks for the confirmation.
Bonus - set the automatic background interval period in hours using a number. 0 disables ABC You should see the number in HA and can change the ABC Interval from there.
number:
- platform: modbus_controller
modbus_controller_id: sensek30
name: "ABC Interval (hours)"
address: 0x1F
value_type: U_WORD
Guys, for some reason the the K30 is not responding on UART. I tried i2c and it works fine. Any thoughts? I am running it on a Wemos d1 Mini
I am getting this error on the serial monitor:
⸮ ⸮⸮[0;36m[D][modbus_controller:029]: Modbus command to device=254 register=0x03 countdown=0 no response received - removed from send queue[0m
Any help would be greatly appreciated thx
Describe the problem you have/What new integration you would like
Integration of the Senseair K30 sensor, or update of Senseair S8 integration to also include the K30 sensor
Please describe your use case for this integration and alternatives you've tried:
Expansion of useable CO2 sensors with (hopefully) little effort.
Additional context
UART communication with the K30 sensor works similar to the Senseair S8 sensor, which is already integrated (see https://www.letscontrolit.com/wiki/index.php/S8). However, when using the Senseair S8 integration, a "Reading from UART timed out at byte 0!" is received most of the time. Only randomly a correct value can be received (but it happens once in a while. The setup works flawlessly with Senseair's Arduino code.). Pull request #2658 fixed a similar problem for the Senseair S8. As far as I understood, the K30 works the same way as the S8, but maybe a different solution for the delay as implement in #2658 is required.