Or when done by the founders… 
This reminds me to find a solution for my Mitsubishi thermostat… And to finish developing an equivalent elsewhere, including other Mitsubishi platforms… Would also be interested if others here use Mitz systems… Feels like there are existing solutions here that people can rely on…
I don’t know exactly what kind of device that is, but if there’s no NR node, there may still be a library in npm:
Or maybe one written in python, which is also a possibility to use if there are no other solutions, either directly or by porting it to TypeScript or JavaScript.
I could port my own… 
I wrote my own in Groovy that eventually morphed into one that tried to cover MELCloud (Europe), Kumo (US) and MELView (Aus/NZ). I’m pretty sure there are examples for EUR and US that could be used in HA, and potentially my own… But it would be interesting to use my own as a mini-project to develop something myself… If I can be motivated more than I am to finish the Groovy version…
If you want to keep it simple and since you already know the protocol you could probably even do it with just function nodes, subflows and http, tcp and/or udp nodes, all directly in NR. Just a thought.
While I don’t want to dismiss adding something to the platform… I feel like others have done a better job than I have… so would prefer to direct people to those solutions…
So with the more formal stuff out of the way… I will find out what can and can’t be done already and what I might be able to add, if only for my own use case…
Thanks for the encouragement @markus. Something I need every now and again…
There’s always one more device/service to add 
I do understand though, and a bit of the beauty with what can run on CORE is the fact that you can run code from many types of libraries, different languages etc. Sometimes doing it with just a few nodes can be neat though, like the LightwaveRF integration I showcased a few days ago. Pure NR talking over UDP.
To be fair, a thermostat seemed like a relatively simple “in” for developing a driver having done a couple of simple drivers… but quickly grew into something more… admittedly due to trying to combine the three platforms… but still complex nonetheless…
I’ll be guided by popularity… If not my own need…That’s my out… If the masses demand it… then… I’ll think about it…
Thermostat drivers do tend to go that way, and you also don’t want to mess them up, it can have expensive consequences… I’ve written a driver to communicate with my Daikin AC over their “special” bus, THAT is a chatty protocol, and if you stop responding it shuts down… All in good fun!
Happy to be the Mitz guy, but equally happy to be the guy directing people to a solution someone else is maintaining… ideally maintaining well…While I work away on my own… But if asked I will ultimately say yes…
Search around on npm and GitHub, your options for what runs on CORE are rather broad, some things just need a thin “translation” layer around the API, such as things written for Homebridge. Plenty of things written for Homebridge can be used outside of Homebridge, for example.
I do believe that many of the 3rd party integrations for CORE will be of the type that they wrap an existing library and just clean up the input/output to fit nicely with everything else.