I have several motorized shades that I have set up and are working (even, with IFTTT integration). I set it up as a ‘fireplace’ after seeing something online about it. I read that this approach also works if you set it up as a ‘ceiling fan’ but I didn’t test this.
I have several motorized shades that are sold/rebranded by Dooya. I was able, after setting up a new ‘fireplace’, to set ‘on’/‘off’/‘up’/‘down’ actions to the up/down control on the remote. I just changed it to the proper remote channel and Bond learned it perfectly. So, although it’s a bit hacky for now, it does indeed work!
However, I have a new motorized shade by Rollease Acmeda. This motorized shade uses some kind of proprietary Rf technology which they call ‘ARC’. Bond was able to ‘learn’ this remote too, however, it won’t control them at all.
Rollease Acmeda sells its own hub called ‘Pulse Automate’, but I’d rather just use my existing Bond!
Some other users have reported similar issues from various Rf devices; see:
I’m wondering if it’s the frequency or if there is some kind of special ‘learning’ code that is separate. I’d be willing to do some troubleshooting if there’s a way to get a command line output of what Bond is able to read?
Have you looked into running the Beta firmware and apps?
Contacting @merck or @jacob via private message could get you set up.
Unless your Bond Bridge has a serial number beginning with ZZ, in which case you don’t even have to get manually added to the beta.
With that beta firmware (or the default ZZ firmware), it is possible to access command line insight (via cURL) into the various commands for the devices you’ve paired.
I just installed the beta firmware, and taking a look over the cURL/API docs now. I have retrieved some of the signal parameters via cURL so will inspect things a bit further and see if I can get it to work! I wonder if this device uses GFSK.
Interestingly, on the back of the remote it says the frequency is 433.92 MHz so not sure if that is an issue? I ran the learning command 3x, and got completely different data sets. Is that normal? Is there some way to know if this is GFSK vs. OOK based on the data fields?
Not sure. Chris Merck shared a few technical details in /v2/devices Not Getting All Devices - #23 by merck, but was more about the database and the API calls themselves; he didn’t mention radios / frequencies / GFSK (and I admit I only have a Google understanding of what that would mean).
For what it’s worth, I’ve seen that sometimes GFSK can be simulated using OOK. (GFSK receivers may respond to an OOK signal, but with somewhat less range.)
Thanks for sharing @merck, that seems like a useful tool. I’ll consider buying it for experimentation purposes. This company already offers a $100 hub, but would like to avoid buying yet another device to control a single shade.
From some more web research, it looks to me that some kind of rolling codes are being used here.
Seems we’d have to crack the encryption in order to figure that out? There is a ‘learn’ technology with these remotes which can be used with the P2 button (and probably needing a sniffer of some kind to get that identifier) but not sure how I could even implement that once I had it…
@merck Now that shades support is out, I really like how the pairing process works with Somfy shades.
It doesn’t work for these shades, however. Is there any kind of debugging I could do after pressing the pair button on the remote for example to help facilitate support for these?
Also… any word on IFTTT support for Shades? For now I’m just calling my Shades a Fireplace and using the standard ON/OFF.
Our SmartThings integration might work for you, there’s a shades controller available there that you could hook into various automations. We have no plans to add Shades support for IFTTT.
@dxdc: So, you have both Somfy and Rollease? Whoah!
We have (as yet quite nebulous) plans to allow implementing complex device templates yourself in a “BondScript”. However, that requires already understanding the RF protocol that you want to implement. So somebody in the community would need to write this template.
That said, if/when we have 1st-party Rollease support, I’m sure you’d be the first to beta
Yeah… the guy I bought the blinds from changed his motor manufacturer… and said the old ones weren’t available.
It’s definitely some kind of rolling Rf code from my previous exploration (you can scroll up). I’d be happy to write the script (am a developer also), but not sure if these rolling codes would be supported?
@merck@jacob I bought an SDR and found out that it seems (?) these remotes just emit normal ASK. The patterns seem consistent anyway. I’m sharing the signals from a single “up” command (top) and a single “stop” command (bottom). They look consistent over several runs.
I will say, the original pulse is very long and it has a hard time even with autodetection. To give you a feel for it, the initial (longer) pulse is 140ms long. My suspicion is that the codes for stop/up/down are: fffff8108, fffff8108 421, fffff8108 021. Maybe Bond isn’t considering that there could be such a long initial pulse?
I bought an arduino to tx 433 signals but didn’t have luck getting that set up yet. Still, I can see from the Bond API I can store the signal data at a certain baud rate. Is there a way to translate this hex data I’m showing into the baud-rate type hex data that is used by the API?
Appreciate your expertise and help! Happy to share these files as well (raw) if it would be helpful for your troubleshooting.
Maybe Bond isn’t considering that there could be such a long initial pulse?
Bond records 0.6 sec of OOK modulation at 40kHz. If we find a match in our database, we return a panel with cleaned up signals. However, if we don’t, then we just try to transmit whatever was recorded in that 0.6s 40kHz OOK buffer.
Is there a way to translate this hex data I’m showing into the baud-rate type hex data that is used by the API?
I’m not sure what your demodulation chain looks like, so it’s hard to tell. The Bond signal/tx endpoint currently only accepts hex encoding at 40kHz (so you’d need to re-sample your data), or “cq” encoding (binary with some shorthands) at 100Hz–40kHz.
Keep in mind there are other possible modulations. (G)FSK is supported by the Bond’s radio but not (yet) in our firmware, for example.
arduino to tx 433 signals
Not sure what you have, but many of these accessories transmit only OOK based on a single GPIO from the Arduino. There are SDR transmitters (like HackRF) that are able to transmit (essentially) exactly what was received without being restricted to a single modulation. Though the cost there is higher.
BTW, there’s a few tutorials for learning about FSK modulation here: fsk
I hope you’re doing this because you enjoy the challenge and learning opportunity! (If it were easy we would have already added support for this shade )
@merck, thanks for your helpful advice. It’s been quite a learning experience diving into Rf, that’s for sure… but fun. I also found rtl_333, which has been eye-opening.
I ended up doing the following after a lot of failed experimentation - I recorded the signal a few times on the Bond device. Then, I extracted that signal with the API, and compared the length of the 0’s and F’s with measured pulse widths to recreate the signal, and then sent that back to Bond.
While it did store/transmit the signal (and I thought it was a clever idea), it didn’t work I’m not sure how sensitive it could be, happy to share the files if you’d be willing to have a look? I have them in complex or WAV format. The signals are very closely aligned though, so I feel there must be more to it.
I’m wondering if it’s something with the modulation as you point out. There’s something funny I think with the modulation in that initial (long) pulse… if you see it’s not a flat line. This is demodulated with ASK.
I’ve also read some about Manchester encoding, which seems like it could be used to create the pattern above. Any advice you have at this stage would be appreciated! Also, if there is some kind of special logic that was used to create the Somfy pairing - I imagine this could be similar?
I really think it’s using some type of ASK. You can see a consistent, but different, kind of pattern embedded in the signal. It’s very consistent though upon multiple remote presses, so I feel like it must be doable.
For now I’m just calling my Shades a Fireplace and using the standard ON/OFF.
