Force configuration worked. Status changes, alert triggers, shows up in logs… the whole deal. When I try to open my doorbell alert rule I get the unexpected error message. Nothing shows up in the logs with the error. It seems like the rule works though.
You may want to delete that rule through the IDE and start over.
I’m going to remove the force configuration settings tonight and remove all the reporting lines from the configuration save section. The configuration will always be sent since it won’t take nearly as long to save. I’ll add some new method of outputting all the reporting information so it can be done on demand instead of automatically.
Sounds like a plan. I’ll be on the lookout for the updates.
I’m up and running now. Did a full reset on the device and I’m using your 1.6a version, however I left secure commands on and it looks like I’m all set!! Thank you!!!
I’m not sure if it was the device reset, moving closer to the hub, or that missing association line I added, but I’m glad to hear it’s working. I’ll include the changes I made to the test file in the new version I release tonight.
I’m also going to add some documentation that includes rule machine examples.
If you notice the top part staying lit up after the track stops, turn the force config option on.
[RELEASE] Aeon Labs Multifunction Doorbell v 1.6
The full documentation is in the first post along with a link to the latest version.
This version should fix the secure pairing problem that a lot of users have been having with this DH and the others. If it doesn’t, you should still be able to use this DH because there’s a setting that allows you to turn off the secure commands.
1 Like
Thanks again. I’m not sure either. When I paired this time I left it in place about 10 feet from the hub, but I clicked the action button repeatedly while pairing (read that somewhere). All in all its working pretty good. Now I just need to find some sound files.
1 Like
Anyone seeing a delay in the action? I’m using Rule Machine to sound a chime when a contact opens / closes. Before I had the Aeon doorbell I was using a custom Pushover device type triggered by rule machine.
I am using the exact same rule as Pushover with the Aeon Doorbell and interestingly enough the Pushover notification sounds before the Aeon Doorbell. I would say the Doorbell delay is about 2 - 3 seconds.
Could it just be the default doorbell sound file? I still have yet to load any custom sounds.
I see a 2-3 second delay with my rule machine rule as well, but I don’t think it’s related to the sound files. There’s almost no delay at all when using the physical doorbell button, regardless of the sound file used. I think it’s more related to the delay of the doorbell reporting it’s status to ST, then the rules being processed, then the command being sent back to the doorbell. I haven’t loaded any custom sounds as of yet.
This may be my fault. I increased the delay time between commands to 500ms because some of the configuration reports weren’t getting displayed in the log and I was concerned that it may also be skipping some of the configuration set commands.
I’ll take a look at it tonight and if that is causing the delay, I’ll use different delays based on the actions being performed which should solve the problem. If that’s not the problem, I’ll see if there’s anything else I can do with the code to improve performance.
I would have added the Rule Machine documentation last night, but my Android app was and still is messed up so I can’t open any SmartApps that use dynamic pages.
Besides the delay, have you experienced any problems with the latest version?
Personally I’m not having really any other issues with the latest version. The delay isn’t really that big of a problem.
The only other thing I noticed, but I think its just the device itself. Is when using it as a door chime (open / close). Sometimes the commands are sent too close together and only 1 will make it through. For example when letting out the dog the door is open for only a quick second before its closed. I think because of the delay it causes the commands to run into each other.
I’m just using Rule Machine to toggle the switch on contact open. Maybe that’s my issue.
I’m still at v1.5 at the moment, but I haven’t noticed any issues with that.
I added the delay in version 1.6 so if you’re seeing it in 1.5, that must not be the problem. I’ll review the code again tonight and see if I can make any improvements.
Well cool, glad I could contribute to that. As I said, it’s not a horrible delay, I only use it as a door chime, so 2-3 seconds doesn’t matter much. I’ll hang on to v1.5 since it’s working for me, in case you need any specific information from that version.
When the doorbell button is pressed, the device turns on, but it also turns on any time a track is played. The only way I could get it to tell the difference is by setting a “playing” flag in the play command and clearing it when the device turns off.
If you played too many tracks too quickly, the off command of one track would clear the “playing” flag of the next track so when the device turned on the flag wasn’t set and it treated it like a doorbell button push.
To “solve” that problem, I had to add some logic that prevents tracks from playing too close together. That logic occasionally got stuck when you were playing a lot of tracks back to back through the mobile app so I had to add additional logic that overrides that functionality after 3 play commands are sent or 20 seconds have past. (You have no idea how frustrating it was trying to get this to work, I’m surprised I still have hair)
I’ll play around with it to see if I can queue the blocked commands instead of just ignoring them. If it’s something I can easily implement and it doesn’t cause other problems, I’ll add it as an optional feature that is disabled by default because some people may not want it to work that way.
Another solution might be adding an off() command to your rule before the playTrack() command, but I have no idea if that will actually work.
I’ll play around with it to see if I can queue the blocked commands instead of just ignoring them. If it’s something I can easily implement and it doesn’t cause other problems, I’ll add it as an optional feature that is disabled by default because some people may not want it to work that way.
I wouldn’t spend any time on it. It really isn’t an issue I was just posting it for informational purposes. Your device handler is awesome great work and many thanks!
I’ll try the off command you suggested. Thanks!
1 Like
Sorry for the dumb question, but how do I sequence the actions so the off command goes first?
The reason the button is so fast compared to the mobile app is that it completely bypasses ST. The device handler doesn’t even know that the doorbell button was pushed until it starts playing the track.
I just did some testing and the delay might have something to do with using custom commands in Rule Machine. Can you try changing your rule to use Switch.on instead of the custom playTrack/beep, just to see if it makes a difference?
[quote=“eveezy, post:79, topic:36586, full:true”]
Sorry for the dumb question, but how do I sequence the actions so the off command goes first?
[/quote]That’s not a dumb question, it was a dumb idea on my part because I don’t think it’s possible to make it turn off.
Thanks for the DH; the RV version just would not work for me, but this one is working.
I am also getting the extended delay of about 3 seconds. Per your request, I tried using just a Switch>On instead of a Custom Command with Rule Machine, and the delay seemed to be approximately the same, still around 3 seconds.
I checked the Live Log while this was happening; no errors thrown. In fact, the only entry for the doorbell when using Switch.On was “Playing Track 2 (play: Playing track 2)” and with the Custom Command it was just “Playing Track 3 (play: Playing track 3).”