ESPHome-canopen external component

Recently I was working on project for easy-exposing ESPHome entities to HomeAssistant over CANBus.

The project is splitted onto two parts: esphome-canopen external_component for converting ESPHome entities into CAN nodes and can2mqtt bridge exposing these CAN nodes to HomeAssistant through MQTT server. It follows MQTT discovery protocol, so ESPHome CAN entities appear automatically in HomeAssistant.

I started with my custom CAN protocol, but recenty I moved to CANopen standard. It should enable interesting features in near future, like mapping any existing CANopen devices into HomeAssistant entities.

esphome-canopen should work with any CAN Bus controller supported by ESPHome, like built-in ESP32 controller or external MCP2515 (on ESP32 or 8266 boards)

Example esphome config converting ESP32 gpio switch entity into CANopen device looks like:

external_components:
  - source: github://mrk-its/esphome-canopen

canbus:
  - platform: esp32_can
    id: can_bus
    rx_pin: GPIO22
    tx_pin: GPIO23
    can_id: 0
    bit_rate: 125kbps

canopen:
  id: can_gate
  canbus_id: can_bus
  node_id: 1
  entities:
    - id: blue_led
      index: 2
      tpdo: 0

switch:
  - platform: gpio
    name: "Blue Led"
    id: blue_led
    internal: true
    pin: 2

For now following entity types are supported: sensor, binary_sensor, switch and cover, more will be added as needed.

2 Likes

Dear Mariusz,

Your message is just in time :slight_smile:
I am developing my home automation system with a can bus in the house and your libraries are very interesting.
I followed the same path as you by developing my own protocol but I want to switch to a standard protocol.
On my side, the hardware part is working, I will be able to test the comm with the opencan protocol.
Do you try your lib with the can nodered ?
We stay in touch :slight_smile:

On my side, the hardware part is working, I will be able to test the comm with the opencan protocol.

Great, let me know if you need any help!

Do you try your lib with the can nodered ?

No, I’m not using nodered - but my can2mqtt follows HomeAsssitant MQTT discovery protocol and these entities are discovered automatically by HA (and I hope they will by simply available in nodered if you have it integrated with HA). Let me know how it looks like on nodered.

Hi,

Is the esp32 library compatible with itself ? :grin:
I.e., an esp32 that retrieves information from another esp32 via the can bus ?

For the opencan protocol, which document did you base it on?

Thanks,
Best regards,

Hi Mariusz,

great work, i use esphome-canopen together with can2mqtt and it works very well, but is it possible to use more then one sensor?
There is a htu21d connected to my ESP32 (temperature, humidity), if assign both entities to opencan then get an error at can2mqtt.

canopen:
  id: can_gate
  canbus_id: can_bus
  node_id: 1
  entities:
  - id: light_wz
    index: 1
    tpdo: 0
  - id: temperature_1
    index: 2
    tpdo: 0
  - id: humidity_1
    index: 3
    tpdo: 0
  - id: cover1
    index: 4
    tpdo: 1

i2c:
  sda: 21
  scl: 22
  scan: true
  id: bus_a

sensor:
  - platform: uptime
    id: uptime_sensor
    name: "Uptime 1"
    update_interval: 5sec
    internal: true

  - platform: htu21d
    temperature:
      name: "Temperatur"
      id: temperature_1
      internal: true

    humidity:
      name: "Luftfeuchtigkeit"
      id: humidity_1
      internal: true

kind regards

it works very well

Great!

but is it possible to use more then one sensor?

Yes. Single TPDO has 8 bytes and there is 4 TPDOs. Single sensor is 4-byte float, so it occupies the half of tpdo. Try different assignment of your sensors to TPDOs (i.e. put 2 sensors in separate tpdo)
I should prepare better documentation of it in README, will do.

For now:

  • binary sensor occupies 1 bytes of tpdo
  • sensor occupies 4 bytes of tpdo
  • cover occupies 2 bytes of tpdo (1 byte for position and 1 byte for state)
  • switch occupies 1 byte of tpdo

Regarding sensors: sometimes sensor should fit in single byte (for example underlying hardware returns single byte). I’m planning to implement optional mapping of float values to shorter integer types, to fit more of them in 4 TPDOs.

I am not familiar with canbus, that explains my mistake, thanks.

Is there a way to evaluate the birth message from homeassistant in can2mqtt and restart the app or create the entities again because they are no longer available after restarting homeassistant-server.

Yes, something like that definitely should be implemented. Can you create an issue on github?

Very interesting project!. I have developped two custom board with esp32 and can bus inteface for home automation.
The first board is used as actuator and contains 4 relay ( 2 for roller shutter + 2 for light control), 2 MOSFET PWM output and 4 input optoisolated for alarms.
The second board contain an esp32 , can bus, 3.5 touch LCD, air quality sensor, temperature ant humidity sensor, motion detector sensor, pir and touch buttons.
I’m going to select the correct library/enviroment for developping the firmware and starting the test/debug the boards.
I’m looking with interest to your project but I’m not familiar with ESPHome and custom external component.
Let me know if you are intersted to collaborate I can share the project with you.

Let me know if you are intersted to collaborate I can share the project with you.

Sure! It looks esphome-canopen should be perfect for your project. I recommend joining our discord server: Discord, I’ll try to help with configuration

Hello, It’s very interessing. What do you use for screen with esp32 ?
Regards,

Hello - I’m reading this with interest!

My house has a lift/elevator which uses CANopen as it’s main bus. As I’m sure you can imagine, it would be awesome to be able to get some if the lift info in/out of HA and interfacing with the bus seems like the way forward. I’d like to be able to get the current floor, door status etc, and ideally call the lift to certain floors. I believe the lift may also send data relating to energy monitoring too.

I’ve got as far as the standard - CiA 417 which is the “Application Profile for Lift Control Systems” and I assume my lift uses this - though I will get more information from the manufacturer before I start further investigations (clearly there is a potential risk to people and property here I need to manage before fiddling with sending data on the bus).

I’m working on the basis that initially I can just read raw CAN packets via an ESP and CAN interface, and reverse engineer some of the data I’m looking for - e.g. check what packet is sent when I press a call button.

While things like the landing call buttons are documented in the standard, I’m guessing I may need to ‘fake’ the node that corresponds to the actual addressing of the call button nodes in my lift configuration.

On that basis, I think I’ll just have the ESP send/receive the full raw packets to MQTT and into Node-RED initially for experimentation. However in time I may be able to use your CANopen library to grab specific packets (e.g. current floor number) as a sensor for easy integration into HA.

You clearly have a more detailed understanding of CANopen then me - does this sound like the right approach?

Obviously I doubt many people here have lifts in their houses, but in time perhaps I can report back with some of the config I’m using in case it does happen to be useful for others. In theory there is a standard so that could be useful.

And if anyone else searching for ESP/ESPHome/HA/CANopen comes across this post and has a lift - get in touch and we can share notes!

Thanks!