Thats great to know. The threads I was reading mike just called them logs, he didnt specify event logs. So that led to my database confusion.
Is there any way to prevent this entirely? Im on a C5 and with the predisposition of these hubs to encounter slowdowns over time every little resource i can save is a plus.
Im using 8.1.0 and the generic RGBW controller.
using template MI-BW210-999W for all but 2 or 3 which are using the alternate template for these bulbs
I understand the confusion, I was also confused when I started with HE, the documentation is very scattered.
Write your own drivers and don't use "Current State"... Just kidding, kind of... You need to write actual events there. I know all devs that know what they're doing will try to avoid writing there unless needed. With that said, if you use for example one of my drivers to monitor Energy usage and set update frequency to 10 seconds and you have a fluctuating reading, that will be a lot of data very quickly, since the value changes.
That driver doesn't have a log.warn that could generate a null log, very odd... If you'd still get it in my new driver when I release that one, I'll hunt it down. As it is now, I will only update critical and truly broken parts of my older type of driver. What is coming is almost a complete rewrite.
Yeah I've only had my hub about a month and only got to spend a few hours with it so far so definitely not up to writing my own drivers, yet.
That is a bit odd about the warn log, but i can be patient so ill look forward to your new driver, thanks for all the work you've put in on this!
Any chance you are updating to using the latest 8.1.0.6 version of tasmota? I mainly ask because the connectivity fix it implemented seems to have solved the random disconnect issue i was having with some of my bulbs on previous versions.
Haven't had your modified version installed long enough to tell if it is affected the same as the "official" tasmota firmware.
If you do experience disconnect issues, do tell me. I will upgrade, I usually just don't do it very quickly since I prefer to not have it changed too often. But if someone experience issues with a version and there is a fix, I'll upgrade faster.
Great, it will be worth the wait, though one major difference is that all devices will have a child device. This is because there will only be ONE driver for all types of devices... Anyway, more about that when it is ready.
This doesn't seem to be an issue with my driver, I get the exact same behavior from the built-in "Generic Component RGBW" driver. I've not searched the forum for if this has been discussed/reported, but if you do and find something, please tell me.
I'm not surprised... I did some research and wasn't able to find it reported, so I logged it as a support incident.
While playing around with setting up new devices, I think that I may have found a bug. A device can easily get deleted accidentally. Here are the steps to reproduce:
I've also found that in that same Child app screen, if the name is changed it duplicate the device sometimes instead of renaming it - A new one is created with the new name but doesn't work. The original device/name is still present. Repeating this a second time (I tried to reproduce the steps...) - the device renamed properly...
I'll follow that thread as well, good to know what they say.
Thank you for reporting this, I appreciate it! Tasmota Connect will however be retired, I'm writing a completely new App. Tasmota Connect was written to fulfill the need of having something/anything to install Tasmota devices. The majority of the effort has been spent on the drivers.
The new App should be free of bugs like that, but if you do find them when that one is released, I will hunt them down and squash them. As for Tasmota Connect, I'd recommend only using it to get the device installed, don't use it to manage already installed devices. The new App is a WIP, but it is getting there:
I'm certain I am only one of many who is looking forward to trying it out!
I feel like it would be beneficial to go ahead and go with 8.1.0.6, as i have noticed my lights are more likely to use the AP with the best signal strength and SNR (going by my routers).
Using the lower revisions I will have lights for some reason chose to remain connected to an AP with 20% signal and a SNR of under 10, ignoring the other AP which a signal strength of 80% and a SNR of 46. It still happens some on 8.1.0.6 but not nearly as often and usually seems to correct itself over time.
Side Question... Is there anyway to have the tasmota firmware set the ip our devices will use? Or will your upcoming release negate the need for setting devices by ip? i never could get the connect to work properly (may have just been too impatient) and was still having to set by ip address manually.
Ok, I'll merge in the changes and release it soon, maybe even today.
I don't experience this in my network, but I only have 3 APs for the IoT WiFi, and each AP has a transmit power setting appropriate for the location, among other things.
Not in the firmware, no, I would always recommend to use a static DHCP lease for these devices. It actually does switch to using the MAC as network ID once it knows it. Once it has done that, it can follow IP changes as long as HE is on the same subnet.
As far as auto-discovery goes, there's still issues with broadcast message flooding I'm looking at nailing down. I'm also considering a network-scan approach, it could be done fairly quickly, but this is not something I've decided on as of yet. This of course only works if HE is on the same subnet as the devices, or you have equipment forwarding broadcasts beyond the one hop these broadcasts send. I try to write these drivers so that they work in the broadest possible set of network topologies, while still being "easy" to use for the average HE user.
It all requires time, I have the background for this, but even so it is a complicated platform to write for.
This has been talked about at length in this forum, and I guess we will never see it, we can still hope, but don't count on it. The only "metric" we could possible have would be based on analyzing the logs and the time between entries and how that time changes.
@markus, would you consider pulling in the bare, MQTT, recieve part of [RELEASE] Sonoff (Tasmota) Intergration via MQTT as an optional way to receive asynchronous updates from Tasmota devices? That would allow those of who already have and use an MQTT broker to use unmodified, Tasmota firmware or other, third-party, Tasmota firmware.
Welcome to the community @istwok!
I've been considering to make a version of my driver with MQTT support since I want to experiment with the group-messaging capability. I believe I should be able to turn on and off all lights in my home at the same time with that. With that said, it will be after my new driver is released and when I have the time, but I'd say it is on the possible roadmap. I will be able to re-use most of my code and the extra code needed is rather straight forward.
Which other third-party firmware are you referring to? What's the functionality you need?
@anon62731458 It will be delayed a day or so, there was an issue with merging. It will not be a full release, just a build I'll make available since this comes from the dev-branch of Tasmota. I would not recommend anyone who doesn't NEED features in this build to use it. I'd wait for a new full release. If you didn't need it for wifi-stability I would not release this as a build at all.
@markus I Don't NEED it... All my bulbs can connect just fine on the stable branch, just they are more likely to pull a better signal with .6, so please just focus on your next release so you can get to adding the MQTT functionality as well... Group messages should let us all get rid of the last of the popcorn effect 
Besides once i rework my wifi network in the next couple months it wont matter at all anyway. been waiting until I have time to run cat wire through the walls and ceilings and also pipe some out to a couple spots in the yard so i can do it all at once. Been doing so much i completely forgot i had that planned 
Keep up the great work!
Sure, the next release will not have MQTT support, it has a lot of other nice things though, like "one driver to rule them all" with auto-detection of what is running on the device, but yes, it is coming, I also want to get rid of as much of the popcorn effect as possible. It is already improved with the new driver through use of asynchttp calls, but MQTT is the next step to improve this since HE have issues when I try to do this with 40 lights at once... Or even just 30. Not that I truly need to do that for a normal use case, but still. MQTT will always be OPTIONAL with my drivers though, so for those that don't want/need MQTT, don't worry, everything will still work without it.
Yes, it does work best when not using mesh networks, my new home was fully wired with CAT6 when I moved in 
Lucky you... my house was built in 1903.... im lucky it had electric wiring lol
Im not meshed, perish the thought. I just have some cat6 running across the floor between the routers and cant put them where i actually need them for good coverage until i can get the wire in the floor/walls because of granny and the trip hazard.
I grew up in a house from 1918, so I understand, needed some updates...
Great to hear! Mesh wifi with wifi IoT... fun...
Hope you get it installed soon then, it's very nice when done!
Thanks. I've been lurking for a while and wanting to bring this up but got busy with other things the last couple of weeks.
That would be excellent. I've been using MQTT so some smart switches can notify the corresponding, smart lights to turn on/off without have to go through HE.
Tasmota - digiDIM Kinda Sorta Not Really Temporary Fork @ 8.1.0.1 - Core 2.6.1
He has some improvements to the Martin Jerry SD-01 Dimmer. I have a handful of them that I will be deploying soon.
I don't have any of those devices myself, but now that there is TuyaMCU support in the main Tasmota release, I don't truly see this as needed, but maybe there's some feature I'm missing? All should work without using that firmware. I'd love to know what is not working with those devices with my Hubitat version of Tasmota.
The main thing that differentiates the MJ dimmer (and its siblings) from most other dimmera out there right now is that it doesn't use a TuyaMCU. Consequently, all of the buttons can be repurposed. I intend to use at least one of the dimmers to control a smart light. I hope to someday not too far down the road use some of them to control a lights and ceiling fans. The dimmer up/down buttons would repurposed to control the fan speed via MQTT or other means.
It might be that the other improvements to Tasmota aren't applicable to HE or your driver. I know Digiblur uses Home Assistant. I'll find out if his changes are needed when I deploy my units.
Ok, I understand, let me know how it goes and if changes are needed we can talk about that.
Download the Hubitat app
