Add support for Regency ceiling fans #1948
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Not all architectures default to 32 bits for an Int, which this variable requires. It is not definitive in the C spec. Using these typedefs guarantee the decoder will work on all platforms.
… On Jan 21, 2022, at 11:37, Christian W. Zuckschwerdt ***@***.***> wrote:
@zuckschwerdt commented on this pull request.
In src/devices/regency_fan.c:
> + // Calculate nibble sum and compare
+ int checksum = add_nibbles(bytes, 2) & 0x0f;
+ if (checksum != bytes[SUM_BYTE]) {
+ if (debug_output > 1) {
+ fprintf(stderr, "Checksum failure: expected %0x, got %0x\n", bytes[SUM_BYTE], checksum);
+ }
+
+ continue;
+ }
+
+ /*
+ * Now that message "envelope" has been validated, start parsing data.
+ */
+ int command = bytes[CMD_CHAN_BYTE] >> 4;
+ int channel = ~bytes[CMD_CHAN_BYTE] & 0x0f;
+ uint32_t value = bytes[VALUE_BYTE];
should be plain int
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications on the go with GitHub Mobile for iOS or Android.
You are receiving this because you authored the thread.
|
you lost me, I see a single byte? (and then |
|
uint8_t bytes[NUM_BYTES]; sprintf(value_string, "speed %d", value); So we have u8->u32 and then %d in the sprintf. When reading about printf %d needs int. And int will hold u8 so I don't understand what you are referring to. In practice this means nothing but I aim to keep things as simple as possible if possilbe. |
|
Using the standard uint8_t-like typedefs in stdint.h is only part of the solution. For printf/scanf there are the constants defined in inttypes.h - these really are part of the C99 spec.
https://debrouxl.github.io/gcc4ti/inttypes.html <https://debrouxl.github.io/gcc4ti/inttypes.html>
Examples:
PRId8 <https://debrouxl.github.io/gcc4ti/inttypes.html#PRId8>
Format specifier for printing an integer of type int8_t or uint8_t as a signed decimal integer.
PRId16 <https://debrouxl.github.io/gcc4ti/inttypes.html#PRId16>
Format specifier for printing an integer of type int16_t or uint16_t as a signed decimal integer.
PRId32 <https://debrouxl.github.io/gcc4ti/inttypes.html#PRId32>
Format specifier for printing an integer of type int32_t or uint32_t as a signed decimal integer.
PRIdFAST8 <https://debrouxl.github.io/gcc4ti/inttypes.html#PRIdFAST8>
Format specifier for printing an integer of type int_fast8_t or uint_fast8_t as a signed decimal integer.
PRIdFAST16 <https://debrouxl.github.io/gcc4ti/inttypes.html#PRIdFAST16>
Format specifier for printing an integer of type int_fast16_t or uint_fast16_t as a signed decimal integer.
PRIdFAST32 <https://debrouxl.github.io/gcc4ti/inttypes.html#PRIdFAST32>
Format specifier for printing an integer of type int_fast32_t or uint_fast32_t as a signed decimal integer.
PRIdLEAST8 <https://debrouxl.github.io/gcc4ti/inttypes.html#PRIdLEAST8>
Format specifier for printing an integer of type int_least8_t or uint_least8_t as a signed decimal integer.
PRIdLEAST16 <https://debrouxl.github.io/gcc4ti/inttypes.html#PRIdLEAST16>
Format specifier for printing an integer of type int_least16_t or uint_least16_t as a signed decimal integer.
PRIdLEAST32 <https://debrouxl.github.io/gcc4ti/inttypes.html#PRIdLEAST32>
Format specifier for printing an integer of type int_least32_t or uint_least32_t as a signed decimal integer.
… On Jan 21, 2022, at 1:16 PM, Benjamin Larsson ***@***.***> wrote:
uint8_t bytes[NUM_BYTES];
uint32_t value = bytes[VALUE_BYTE];
sprintf(value_string, "speed %d", value);
So we have u8->u32 and then %d in the sprintf. When reading about printf %d needs int. And int will hold u8 so I don't understand what you are referring to. In practice this means nothing but I aim to keep things as simple as possible if possilbe.
—
Reply to this email directly, view it on GitHub <#1948 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AA5OEGZWKU64E7LS5OVUYZLUXGPI3ANCNFSM5MOBWX5Q>.
Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
You are receiving this because you authored the thread.
|
|
bottom line: we have a lot of code to manage, we need it simple, plain and uniform; all decoders should roughly look the same, the odd ones are not great and need to get fewer. And the PR is likely the only chance to get help by the author. Thanks for sticking with this and working through all the requests. Looks good to merge. |
|
LGTM |
|
Hi there, There are also fan_speed command on the same channel but I don't know whether this makes sense at all... Let me know if I can help with more data, but I don't know the owner of the device.... |
|
Sheilbronn,
My first guess is that what you're seeing is not a regency remote but something else that uses a similar-enough protocol to be decoded. Unless the owner of the remote has 4 fans, you won't see the channel jumping around, and the fan speed values would increase/decrease monotonically, not go from 'stopped' to 'two' in one go.
If you want to capture more data I can see if I can tighten the code to more accurately detect a regency remote. Use the -S option with either 'known' or 'all'.
… On Apr 26, 2022, at 3:01 AM, sheilbronn ***@***.***> wrote:
Hi there,
I seem to have a regency remote control in my suburban environment and I noticed some invalid percentages (192%, 195%) being emitted. Are these valid values or should the corresponding signal be suppressed before output?
26 06:25:38 {"protocol":211,"model":"Regency-Remote","channel":15,"command":"light_intensity","value":"192 %","mod":"ASK","freq":433.85,"rssi":-9.729,"snr":6.362,"noise":-16.091}
20 17:18:52 {"protocol":211,"model":"Regency-Remote","channel":15,"command":"light_intensity","value":"0 %","mod":"ASK","freq":433.883,"rssi":-2.178,"snr":4.2,"noise":-6.377}
18 19:44:25 {"protocol":211,"model":"Regency-Remote","channel":11,"command":"light_intensity","value":"0 %","mod":"ASK","freq":433.854,"rssi":-1.383,"snr":12.218,"noise":-13.601}
21 19:49:24 {"protocol":211,"model":"Regency-Remote","channel":1,"command":"light_intensity","value":"195 %","mod":"ASK","freq":433.927,"rssi":-6.751,"snr":12.841,"noise":-19.591}
23 20:57:12 {"protocol":211,"model":"Regency-Remote","channel":7,"command":"light_intensity","value":"64 %","mod":"ASK","freq":433.898,"rssi":-4.097,"snr":4.336,"noise":-8.434}
There are also fan_speed command on the same channel but I don't know whether this makes sense at all...
I attached the Regency readings that got picked in my logs recently as a file attachment: regency.log <https://github.com/merbanan/rtl_433/files/8560632/regency.log>
Let me know if I can help with more data, but I don't know the owner of the device....
Shall I open a separate issue?
—
Reply to this email directly, view it on GitHub <#1948 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AA5OEG4MQJ6M7VDXOEB3RM3VG6IEHANCNFSM5MOBWX5Q>.
You are receiving this because you authored the thread.
|
@dtiller : I'm happy to give it a try. These signals are quite rare, though.
I restarted rtl_433 with -S known. |
|
Ouch! You might want to enable only the regency decoder and select known. I think that would be rtl_433 -R 211 -S known etc
See if that doesn’t record everything.
… On Apr 26, 2022, at 10:24, sheilbronn ***@***.***> wrote:
If you want to capture more data I can see if I can tighten the code to more accurately detect a regency remote.
I'm happy to give it a try. These signals are quite rare, though.
Use the -S option with either 'known' or 'all'.
I restarted rtl_433 with -S known.
Now my log dir is filling up with files named like "g0XX_433.9M_1024k.cu8".
Am I supposed to watch out for the Regency remote signal in my rtl_433 log file and then find out the corresponding cu8 file that caused the signal ?!
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you authored the thread.
|
That's fine. I'm decoding every protocol/signal in my neighbourhood relaying the results to my home automation OpenHAB. I build a wrapper around rtl_433 supporting MQTT Auto Discovery for different types of devices - ugly stuff ;) |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This decoder handles Regency brand ceiling fan commands. I will upload test data soon.