- build flags RF_... are renamed to RFB_...
- drop RFB_DIRECT boolean in favor of RFB_PROVIDER=..., adds RFB_PROVIDER_EFM8BB1 and RFB_PROVIDER_RCSWITCH
- rework rfbridge parser. drop serial buffering and combined processing of rcswitch / rfb data in favor of state-full parsing
- rework rcswitch integration, support variable length payload via bitlength and allow to output 64bit data via rc-switch fork from open-mqtt-gateway.
- apply bit-length comparison for the old rcswitch codes, bump cfg version to 5 to allow 1.14.1 config updates (broken on dev, since cfg setting was never updated on clean installations 😞)
- optional relay support for both, independent of mqtt
- rework settings scanning routine when trying to match rf payload with the relay ID, scan settings only once instead of relayCount()<sup>2</sup> times if we want to find something for relayCount()-1'th relay
- add broker callbacks list with proto id + stringified code. default rfbridge does not support more than one protocol, so send out ID 0 as default (which matches with what 0xa6 will show, supposedly as it does not work for me :?)
- send out 0xa6 and 0xb0 sniffer data from https://github.com/Portisch/RF-Bridge-EFM8BB1/ to the MQTT and internally via broker callback
- update receiver callback 'locking' to make sure specific relay ID is tracked instead of all at once
- update build tests and deprecation notices
Stock RFBridge & RCSwitch refactoring are closely related, so pulling all of this at once. We no longer use the same 'flow', using separate integration paths.
One sort-of breaking thing is the new internal _rfbMatch() change - we no longer update serialized 'buffer' string when matching in the receiver, thus we (very) likely send a different string to the MQTT when receiving the same device's code. This introduces non-trivial dependency on the output buffer though :/ And we don't always have relay support, so that would be another layer of preprocessor checks.
Instead, I am in favor of another option - special build / runtime setting to provide the same protocol + payload pair as new broker integration does. To simplify / make sure it is noticed, separate protocol and actual data with comma, colon (like IR) or space.
- for some reason we were never checking it's output
no need to increase +1 since we write the exact number
- allow hexEncode output be decoded, enforce even-ness
- raw msg must have at least 3 bytes - start+code+end
Per PR comment:
> I'm running simple 1-channel led dimmer and couldn't get brightness control working, as it was called only if lightHasColor().
> This PR changes conditions slightly, and allows domoticz's dimmer device to control brightness as well. I think this device type is more appropriate/comfortable in this case."
- remove lightHasColor() check, try to parse the payload and manually adjust the channels
- when domoticz payload does not have "Color" field, still fall-through to the brightness update
- share relay dummypin instance between relay objects, replace unique_ptr with basic pointer (as we never destroy things, everything is brought up on boot and is essentially static)
- reduce overall size of the Api (web_api_t) structure, store a single required unsigned char id inside of the Api object itself.
- drop std::function for the same reason, current implementation only needs a single u8 ID in all cases
- tweak internal functions to expect a certain path size, drop strange comparisons with sprintf return value
- (kind of a hack) add manual calls to vector<Api>::reserve() as we go over the current capacity and vector increases it's size times 2. e.g. for 9 relays, we would allocate space for 32 Api objects as vector size goes from 16 to 32, after we add 18 Api objects with relay + pulse
- (breaking) json calls on a separate path, don't waste time encoding a single entity as json object when we can encode more things
- rfbridge API learn will return the current status instead of a plain OK
- reduce overall size of the structure, store a single required entity
inside of Api object itself.
- tweak internal functions to expect a certain path size
- (kind of a hack) add manual calls to vector<Api>::reserve() as we go over
the current capacity and vector increases it's size times 2.
e.g. for 9 relays, we would allocate space for 32 Api objects
when vector size goes from 16 to 32, after we add 18 Api objects with relay + pulse
- (breaking) json calls on a separate path, don't waste time encoding
a single entity as json object when we can encode more things
Max Prokhorov
Alex. Tircovnicu
mkozlowski
m-kozlowski