If you could set Insanely Verbose logging and post that together with the above I'd get some context so that I can track it down...
1 Like
I'd love to but it crashed my hub within seconds the last time. Given I dont use my Sonoff RF Bridge right now I think I will wait until my Dev HE arrives one of these days.
I understand, don't get why this is happening though, this we need to find the root cause to, it could potentially affect any of my drivers under "the wrong circumstances". Need to catch this. When you can, I would appreciate more logs.
EDIT: @jchurch This could be because of unresponsiveness of the device. "Read timed out" comes from a httpGet or httpPost call. "Connection Refused " is probably also related. First thing to do would be to make sure that the webpage of the device is responsive. Also, set "Teleperiod 300" in the console. Less is not needed. I will try to simulate these conditions, but I've not come up with a way yet...
As far as catching this error, it is not possible with the current way it is implemented in Hubitat. Thinking about how to "detect" these errors and to stop sending requests until the issue has been resolved.
1 Like
Loaded it up on my hub and moved all my rf devices over to the child devices and have not had issues so far so thanks.
I did however have issues with variability in the codes recognised with the rfraw enabled for the buttons I have so had to disable it in the driver.
My motorised blinds I have do rely on codes that require rfraw to be enabled to be sent so an option for this might need to be considered when you are creating the driver to send codes.
I've been getting around this for a while by use a post command to enable, send the code and then disable it again and this works fine.
Nice to hear it is working. For the buttons, you should be able to get it to work in RAW mode. But I guess it depends on the buttons. I have gotten all my buttons to work really well with RAW.
Though I must say, nothing is as good as RFLink, when it works... When RF Link can receive and decode the signal, it is VERY stable.
For sending I will make it possible to send in RAW and then go back to normal mode, though personally I prefer just having another Sonoff RF Bridge. I set one in RAW mode and one in standard.
What do you think about the "learning mode", is it good or does it need changes? I also assume you found the "advanced" setting for setting the codes manually?
For sending codes to the blinds, which Capability should the driver use to make sense? Just WindowShade? How do you use them? Just fully open, fully closed? Do you have codes for different amounts of open/closed?
Replying from a post in the other thread
@maffpt From what I can see, what you have not done is to learn the code of your smoke detector. Best Debugging logs to use is RF Codes. Insanely Verbose actually doesn't include everything. RF Codes is a separate set of debugging codes which will only include that which is relevant for RF Code connections.
This driver really needs a user guide, my hope is that someone better than me at writing user guides takes care of that 
Activate Learning Mode and save the code used by your Smoke Alarm, then test it again. The codes are unique per device, which is why you need to "teach" the driver to listen for "your" device.
@markus thank you for your prompt response.
I'll try your solution latter today - I'm leaving for my day work now ...
About the user guide, it happens that I've done quite a lot of it - it's a painful chore, specially taking into consideration that most people don't read it ... but I'd be glad to help. If you agree, I can start developing it with the material available with your driver, send you a draft and from there complementing it with additional information you have.
You're welcome, I hope it works as expected.
Thank you for the offer, it is definitely needed. I happily accept. @jchurch has written the initial install and generic instructions, they can be found here:
This driver, the RFLink driver and the upcoming IR driver all need a lot more explanation. They also need feedback regarding improvements.
What I would like is to create a well documented and maintained set of drivers. But for that I hope to over time find people like you and @jchurch who can maintain and update documentation as well as people who can test all the different drivers and come with feedback on improvements. If there would also turn out to exist another developer who wants to collaborate, that would be nice, but right now it's documentation, testing and feedback that is needed.
@markus I turned back on the Sonoff RF Bridge and I confirmed I could reach the Tasmota portal without any issues at all. I then waited a while before re-enabling the device in HE while monitoring the logs with insanely verbose and keeping my finger at the ready on the disable device button.
Anyways what I learn't is the following, with RF Raw Mode (off) that's when the device goes nuts dumping crazy to the logs which I think caused the crash. I then enabled RF Raw Mode (on) and it stabilised I haven't had any issues all morning. FYI I did install both Tasmota HE firmware (yours) and the Portisch yesterday.
Here is some logs for you to look at.
EDIT: I also connected an RF button to see if that worked and it learned the code successfully which was good. My only issue was this particular button is slow to respond as I found that before using Eric's firmware so I know it's this particular cheap doorbell button. If I can find something faster I may look into using RF for the doorbell again maybe something like this. I will give your motion sensor driver a go at some stage and I think I have a contact sensor laying around somewhere too.
1 Like
Thank you for checking this, I believe I have fixed it, I was able to replicate it with your information and then fix it.
Speed should not be a problem if you really managed to get the Portisch firmware in, I have seen it say successful and then actually not be upgraded. Do double check that it is Portisch.
I'm not very happy with any of the motion sensors I've tried, but I'm sure there could be a use for them, just not for room presence... For the water sensor I do believe it will be useful, for that I use both a ZigBee based water sensor and this one, don't want to miss any events like that...
1 Like
@markus, I've prepared a proposal for the documentation. Please let me know how can I send it to you.
Far from exhausting the subject, this proposal is intended to be just the starting point over which we can discuss how to organize the documentation for this and other projects that you have developed or is about to develop.
Let's work!
I've sent you a PM 
Thank you for working on this!
No worries mate I am glad it was useful and that I was able to isolate it in the end.
In relation to my button I am certain it's this specific button it just doesn't have good feedback when pressed it seems to work only now and again etc so I'd need another one to know for sure. Fair enough about motion I haven't tried that yet that's a shame tho, honestly in the end I did buy a bunch of Xiaomi ZigBee sensors when i moved into this new house last month and they work really well so RF has taken a bit of a back seat for me but still happy to get this working as I still think it's a useless tool in the tool chest for me and others in the future.
1 Like
Yes, it definitely could be.
My flat is full of those... I've had issues with communicating through certain walls though. Sorting it out with CC2530+CC2591 and XBees...
I've been pretty lucky with Xiaomi as I am using 13 Nue switches (routers), they are effectively rebadged Zemismart ZigBee switches and in my experience work with Xiaomi well.
EDIT: the only issue I had was with ZigBee bulbs but your Tasmota drivers and flashing Tuya has fixed all that 
That's lucky, I'll get mine to play ball soon as well. I think our bedroom is basically a Faraday cage...
1 Like
The 3 buttons work 80% of the time but data changes slightly for the other 20%. The device was about $5 AUD delivered so can't expect the quality to be perfect. My first thought was also to add in another hub but might look into the the RFLink.
The learning mode was an interesting idea. It worked fine for me so don't think it needs any changes as it is pretty straight forward. I did only use it for a couple of devices to test it out and it will make using the RAW codes a lot easier.
The window shade would probably be the only capability for the blinds.
The codes that they responded to are open and close and stop . There is an option for a preset level using the remote but I have never been able to capture this as it sends out multiple codes to do this. Instead I used a timed delay to send out the stop command from fully closed.
RFLink might even have a decoder for your blinds, then sending the other "special" codes might be very much possible. It's a cheap and simple thing to build. I use the ATMEGA 2560 with an ESP8266 built-in.
Ok, I'll make a driver for this. As for the partially open, maybe you could adapt my curtain rules from here? They work well for my curtains... Not sure if the dimmer approach work with the IR device though... The dimmer is used to make sure values can't go above 100 and below 0. Without any IF statements, that is the best I could come up with...
I actually found my motion sensor to be more responsive/sensitive than my zwave multi sensors but that is probably because I left them rechecking for motion every 2.5 seconds rather than let them go into battery saving mode.
Thanks. I was think about creating something similar so I'll look into adapting your rules. I actually have this setup to install when my new curtains arrive.
Out of interest what does your rule do different to just setting the curtains up as a dimmer?
