I read topic few days ago and now started to build a simple serial binding. I based this on the dsmr binding as I did with my vallox binding. First idea was to make it bridge->thing configuration as the initial plan was so that multiple things could support different data types/protocols. Now I think that this is not the way and we should only have one thing that handles the serial device and transformations with rules are used when handling the data. My questions are is there something that rules can’t handle and what are the absolute minimum that the binding should have included? For example what different settings should be made available.
I was thinking along the lines of a bridge to represent the serial port which supports a string input, string output and a trigger when data is received.
Things could be used to represent reading data from devices without having to use rules. A thing would support a simple regex match to update it’s channels if it matches the input string. A channel would support a transform to transform the data before updating the item.
Although all of that is much more than is required for my simple use case of receiving a string which I currently check with a rule.
Just wondering if this is moving forward. I’m using it to control relays (KMTronic) and my electric curtains (Goelst). What I’m missing is rfc2217 support and proper handling of failures. If a USB device or socat device is disconnected it doesn’t reinitialize properly and CPU load goes sky high.
Yes @MikeJMajor is getting the V3 serial binding through the review process at the moment. So if your on V3 it is probably possible to get a build and help with testing.
