It's generally not recommended to use IP addresses for certificates.
That said, you have several alternatives. If you absolutely must use an IP address as identifier, then you can configure your DHCP server to always give the NIC of the embedded device the same IP address. I use this technique to ensure all static devices in my home have fixed, known IP addresses (e.g. my router is
192.168.0.1, my home server is
192.168.0.2, etc.), and all "dynamic" devices (e.g. phones, etc.) have high IP addresses.
An addition to this is to use DNS. You can use an internal DNS server, which manages a pseudo-TLD such as
.local, and use that to give your devices logical names. For example, you can designate your printer as
printer.lan, and give it the fixed IP address
192.168.0.7. This way, you don't need to re-generate the certificate if the IP should ever change. You just need to change the DNS entry.
But why is it not recommended to use IP addresses for certificates?
This is a legitimate question. It makes conceptual sense to certify that something is reachable under a certain name, rather than a certain address. The CA wants to sign "This certificate is for
printer.lan", not "This certificate is for
192.168.0.7", because as you correctly identified, you really can't know who
192.168.0.7 will be in a month or two.
Logical names, on the other hand, will stay the same. Your phone will never be called
printer.lan, even if it may one day be reachable under