Not much interest has been shown for these drivers, if you want this driver to evolve, show it.
For general Tasmota drivers, go here:
Since these drivers will probably need a lot of explanation and I want an easier way to keep track of feedback on what to improve/add, these are released in this separate thread.
The main thread with the firmware and all other drivers can be found here:
In the above thread are the general instructions on how to use my drivers and firmware. In time more specific instructions will be added in this thread.
WARNING: There MAY be a problem with the RF Bridge driver crashing the hub, I can't replicate it, but if it happens to you, please turn on Insanely Verbose debug logging and provide me with the log by PM or in a post.
So far these drivers are for RECEIVING signals. Sending RF signals will come in a future update. I will also be adding support for receiving/sending IR signals using another type of device supported by Tasmota.
For now, please have a look at these drivers and tell me what you think.
The Child drivers work with BOTH of the Parent drivers.
Sonoff RF Bridge
This device requires you to flash both Tasmota and Portisch (for the RF part). More details to follow.
This device is for 433MHz only.
Tasmota + RFLink
This is for using with an ESP8266 running Tasmota which is connected through a serial connection to an ATMEGA2560 with RFLink on it. More details to follow.
This device can be used for various frequencies, it all depends on the receiver/transmitter you use.
Alright so I loaded Tasmota HE firmware onto the Sonoff Bridge RF and then installed Portisch HEX file after that which seemed to all work fine. I then loaded your Sonoff RF Bridge driver into HE but it seemed to spam the logs and slow everything down. Any other steps I am supposed to complete here?
EDIT: It crashed my HE so I just had to force reboot it. Ouch.
EDIT: I didn't load any of the child sensor drivers into HE, was it maybe searching for them?
I'm very sorry it crashed your hub, and I really want to understand why.
What did it put in the logs?
Not having any of the Child drivers would be a problem (RF/IR Switch/Toggle/Push (Child) is required since that one is loaded first when the child device is created, then you can choose whichever one is suitable). I have added a check for if the Child driver is installed, if it isn't an error will be shown in the logs and nothing else will happen.
As for Debug Level, probably best to only run RF Codes debug level, or None. To debug the connection to the RF Bridge, the the RF Codes debug level is enough.
If you dare trying again, please tell me how it goes
No worries. Can you maybe remove the check for child devices? In this case I didn't have any I was merely connecting the Sonoff RF Bridge up to get it to a point of working and i'd imagine others will initially do that too which could lead to a crash. Thoughts?
If there is no child device driver now, it just puts an error in the log suggesting you must have forgotten the child driver... So now it should be fine. ONE error per child device set, and time you run Configure, so no flooding...
DOH... it crashed my HE again in fact even quicker than last time. What am I missing here?
EDIT: I wish I had my new "test" HE but unfortunately my mate in the US didn't get it in time before he came to Australia. I will get it but not sure when.
I don't get it either, I have 0 issues and I've been running this for a few days here already... Any log messages you can share? This is strange for me...
My dev hub is being delivered to China, it's currently in LA, so should be here next week I hope. I'm really looking forward to having one more hub.
Yeah I really wish my dev hub had arrived in time,,,
My logs are basically filled with the following:
dev:12862020-01-03 06:44:17.582 am warnRead timed out
dev:12862020-01-03 06:43:05.800 am warnnull
dev:12862020-01-03 06:41:23.729 am warnConnection refused (Connection refused)
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.
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?
@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.
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.
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.
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.
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...
@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.
