Hi @markus,
I just purchased some RGBW bulbs and updated their firmware to your Hubitat Tasmota (8.1) and they work great! Very good work you did! They are super easy to setup!
One thing I notices - In the dashboard, I setup the bulbs using the "Color Bulb" template. These work great to set the bulb color, dimming level, etc. What I do find however is that the icon will change color (RGB) with the bulb, but when I set it to one of the White values, it continues to show the last RGB color that I had setup. Would you know if this is an issue with the Hubitat Dashboard, or something in the driver? I notice that a tile with 3 lights as a group has the same issue.
I have also setup a power monitoring plug. I have updated the firmware on a CE Smart Home plug (Model LA-WF7) to Tasmota-Hubitat 8.1.0. I can connect to the plug and see that it is connected to my Hub, however it does not respond to commands, either on the physical button or from the web or Hubitat. Could this be a firmware issue? Is there something that you would recommend I do to fix this?
Well, that was easy!!! Yup - That fixed the issue. I had seen information on the configuration templates, but never really understood how it works - I understand it better now - Thank you for that!
This should be gone in my new drivers, which will be released when I have the time to finalize them. If you have the patience. Exactly which driver are you using?
Logs don't go to the database, they go to a file, so don't worry:
Yes, that is true, for attributes, not logs. The link I posted is for one of the main developers of Hubitat, whatever he says about the platform I would take as true and forget about whatever else is said, basically. It's of course up to you to decide how you want to do things.
Event logs are not the same as logs. Event logs reside in the DB and can be seen under "/device/events/[device id]" or pressing the "Events" button on the device page.
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:
From the Tasmota Connect App, Click on one of the installed devices.
While on the Child app screen showing the Device name, etc... Click on Done.
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 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.
