What I'm trying to say is that maybe there is a way to make them feel even safer.Well that’s a wrap, another VMworld in the books, this is number 8 for me and how fast the event flies by never changes for me. They feel safe, because they don't need to expose their devices to the "cloud", they feel safe because they know it is open source and 215 contributors are working on making Tasmota better, they know that even something is not easy to do with Tasmota it will be in the future because it evolves every day, they know that they will find help from community if they find some obstacles or don't understand something. I've got 44 devices running Tasmota in my house, but I do believe there are many users have hundreds of it - people trust Tasmota and using it in a way that probably most of us can't even imagine. There are "Tasmota evangelists" like "dottore" DrZzs, Rob from "The Hook up", digiblurDIY and many, many more which produce dozens of youtube movies, blogs, tools helping people to start using Tasmota - it is a HUGE project which litterally changed people lives. Google returns MILLION results to "tasmota" query. Maybe it can be done by introducing something like sensor29 ,? Changes in MCP driver are of course only an example here, but I hope you get a point: be "safe" during update in boundaries of the same major Tasmota version. Of course I understand that it's not that easy because every SetOptionX consumes memory and leads to situation that there can be SetOption2345 which is unmanageable. ![]() Introducing API change in MCP driver could be moved to the new major version or could be covered by SetOptionX - default is old API interface, but if someone need the new functionality/API and find it interesting it can be changed by SetOptionX. let's say "user experience" (I'm not sure it's right word/term) You are absolutely right that it's not easy or can lead to very strange situations (Tasmota version 987.64.5), I just wanted to point some "inconveniences" and talk about. I don't have ready solution to address all concerns. ![]() Those are just my observations and propositions of changes to (from my perspective) make Tasmota user world even better.īeta Was this translation helpful? Give feedback. new fatures should have the default value set to be compatiblie with previous versions (those with the same number on major position) - SetOption65 to name one, which was introduced ON (or OFF I should say) by default.minor and patch version number changes should be considered "safe" for average user and do not brake compatibility - somewhere between 9.1.0 and 9.5.0, MCP230xx API has changed.should change the version major number - there should "bells start ringing" in user head before upgrading from version 9.x to version 10.x an API change, memory layout change, etc.Maybe you (Tasmota Dev Team) could adjust the way new features are implemented and introduced: Migrating from older versions (even with the same number on the major posiotion) to one including this functionallity can be really tricky, not only because many things could change (be incompatibile) but also because new options have defaults set to values which can change someone's plans for evening or weekend )Īgain - I'm not complaining, this is Open Source project and dev team is spending it's own spare time to move this project forward: adding new things and features, new drivers, new options, help other users to solve their problems, etc. Let's assume that someone find out, that dummy energy monitor sensor was implemented (brilliant idea to tell the truth) and find this solution very interesting. I'm not complaining, because there is version change on the major position (on the other hand I was not able to find this information - change of MCP230xx driver API - in CHANGELOG.md). Not a big deal, I switched sources to v6.6.0 tag, compile and I was good to go (especially that I was putting compenents on my bench lab). Well, it shows up that I could not because mcp23017 driver is reporting its state in different way and my NodeRed flows needs bazillion changes to work with new version. In the new location I decided to go with v9.5 version. My working solution is based on v6.x so it is a bit rusty. Yesterday, I was trying to duplicate solution based on Tasmota, MCP23017 and NodeRed in other location. I'm not trying to fix things which are not broken (still have plenty of devices running on v6.x), but sometimes there is new functionallity or setting which can be usefull or there can be the need to implement the same solution (based on Tasmota and automation created in NodeRed), working months or years in one place, in different location. ![]() I've got many Tasmota devices running at home and other locations.
0 Comments
Leave a Reply. |
Details
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |