I also read the documentation: Generic I²C device component: — ESPHome but the example is too summarized for me to understand. Does someone have a working example of a Generic I²C device component? Not sure if this would be powerful enough for my application, but it’s worth a try.
Details of my project:
I have a custom made alarm system where the main cpu is an arduino device with code I wrote several years ago, which has all the features I need (no more, no less). The hardware lives in a custom made PCB I rather not change, since it’s been running flawlessly for ~10 years now.
At some point I added some code to this arduino so it’s able to report the states to an esp8266 via i2c and also recieve some commands, all using a protocol I implemented in both sides that includes error correction.
As stated above, I need to update the implementation for the firmware in the esp8266 so it does not use the custom component that has been deprecated.
I hope that the answer does not rely on more specific details of my implementation, as there are several people experiencing similar issues, and simply adding the custom component back using the above mentioned github implementation. This will blow up at some point, that’s why the developers decided to drop support for it, but I feel that a clear guide on how to migrate old custom components into proper external components is lacking… Specially for me that I have not written a single line of Python in 10+ years.
Sorry, I’m not able to answer your question, but since you want to update your setup, maybe you should revaluate it from beginning. Quite likely for the same effort you eliminate the arduino from your setup.
Thanks for the answer, but as I said, I’d rather not change the hardware, in fact, I’d rather not update the ESPHome and leave everything as is before altering the hardware. Meaning the arduino must stay. But as I said, I feel that there are several people with the same issue, so we can pretend that the PCB holding the arduino is something I bought and can’t change (although, in my particular case, I am willing to alter the i2c protocol in the arduino side if I realize something else makes more sense while implementing the esp8266 side).
As a further explanation, the PCB where the arduino lives is the same that has all the screw terminals and 12v analog circuitry for detecting tampering, something I much rather not reimplement, also considering that unplugging all the sensors (16) and replugging them is a lot of work on its own.
That’s the best way to my opinion.
If you want to update, and hardware changes are no-go, some other communication could be easier. Uart for example. Another option is to invest your time to learn how to make external component, which probably give you some advantage in future.
You need to start with a description of exactly what your i2c component does and exposes to HA. This will likely result in you discovering that your component is really several things and therefore a compound component.
External components are thoroughly UNdocumented. The gist of the documentation that is generally available is “find an existing component that is close to what you want and make changes to it”. To be really successful at external component creation you need to be proficient in several areas, each of which requires some specific knowledge (that is not generally easily available). Since many people have created external components, clearly it IS possible to acquire this knowledge.
I started learning about external components a few months ago and have some idea of how to do it. It is not easy and not a task that will take an hour or two. How much time/effort are you willing to invest in learning about external components?
If it is not “a lot”, stick to one of the other methods. If you are not proficient in c++, it will be hard understanding what you need to do and why. If you are not really familiar with the data model and structure of esphome and HA some of the reasons for things that need to be done will not make sense.
If you have something working with custom components and want an easy path just use the external component that allows custom components to continue working. Your statement of your concern with that path doesn’t match your willingness to do what it takes to avoid that.
You have a choice to make about what you want your adventure to look like.
Is not a lack of willingness. As you said, is lack of documentation.
I do have have lack of willingness in changing the hardware, also because, even if I remove the arduino and put an ESP as the whole brain of the operation, I would also need to make an external component which would be completely different from what I already have. In the notes about the removal of custom components (About the removal of support for custom components - ESPHome Developer Documentation) it states that basically I’m only missing the Python part to cast my custom component into an external component. But I found no explanation whatsoever on how to make that Python code.
I do not see the benefit on Uart over I2c in this case… I would also need to make a external component to handle the uart comuncation with the arduino. The hard part (I hope the actual runtime code is the hard part) of the solution I need is already done. I only need to clearly understand how to make an external component out of it.
it exposes the status of motion sensors, open door sensors and tampering, all being displayed as binary sensors in the Home Assistant front end.
In the other way, I can send commands from Home Assistant to the alarm system such as: “disarm”, “arm at home”, “arm away”, “sound siren”, “ignore motion sensor X”, etc. I think all of these could be replaced by some cleverly design “switches” at the ESP-Arduino interface level, and then abstract again in the Home Assistant front end.
You see, you have many options.
But why to fix something that works like desired in the first place.
You can update your esphome and all other devices, just leave that one as it is.
Some day in future there might be nicely documented I2C component here.