-
Notifications
You must be signed in to change notification settings - Fork 4.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Use plug without WIFI to switch off power after preconfigured PulseTime #8522
Comments
Please, address this to the Tasmota Support Chat. The chat is a better and more dynamic channel for helping you. Github issues are meant for Tasmota Software Bug Reporting. Please check the Contributing Guideline and Policy and the Support Guide. Thanks. Support InformationSee Wiki for more information. |
Thanks, I think what I would need is a new command WifiConfig 9: 9 = disable Wi-Fi Manager so like 5 but without wait until an AP is available again Then Wifi would be off until I press 6 times the button to start the AP for connecting a different WiFi if required. Would be also required to be able to change the WiFi config option there in the WiFi configuration page however. Maybe offer WifiConfig in a combobox? |
If the above is not implemented my best option is probably to:
|
The request for a command to turn off wifi has been requested before ( that is why this issue is tagged as duplicated ): Please, check those discussions. As a summary, that feature was never implemented in Tasmota because it is outside of smart-home's objectives. If that device can't share information or be controlled, it isn't part of a smart home. If you need help on configuring your plug to switch off power after a preconfigured Time ( may be using rules or If you want a new command to turn off wifi ( or a new If you have concerns about wifi health issues, please check #1805 and #3609. If you want to control your plug but reducing the TX power with a stable connection, please check #4971 and #1879. Thanks. |
Now it is available the command |
Dear Ascillato, Maybe one should adjust these objectives, since the smartest homes these days are all about energy saving and not energy wasting. Also not every home is only a house or an apartment with grid power available everywhere. Especially when there is no grid power and no Power over Ethernet you need sometimes to transmit data event based or on a scheduled basis. Having a device draw 110mA all the time, because somebody defines IoT or Smart Home is grid power based with always on WIFI, is not useful or smart! So maybe one should think about that, when judging future feature requests. I for myself extended the TASMOTA libraries to support MAX17043 for LiPO monitoring for Solar powered TASMOTA devices, but it seems that this does not fit in the current "smart-home's objectives" of TASMOTA. Kind regards |
Thanks for sharing your thoughts.
Yes, we all agree on that. The definition of smart home is that the devices that are part of the home are interconnected, meaning that they share information. If they connect and disconnects is not contradicting to this as long as some information is being shared with other devices. For example, If you have an automatic watering system for a garden, but that system is isolated, it is just an automatic system, not a smart system. However, it is an smart system if the watering system can:
Not really what I wanted to express. I just wanted to make focus on the information interchange. It won't be a smart device, a Wi-Fi capable device that has its Wi-Fi turned OFF all the time, as this issue was about. Check the following statement from the OP #8522 (comment):
That is why, an automatic device was never the focus for Tasmota (meaning we were not going to spend our free volunteer time working on it. If anyone wants to contribute with a new feature, there is nothing against that as long as don't degrade Tasmota's performance and the usage of Flash, RAM and iRAM is low). Tasmota is aimed to smart devices, meaning devices with interchange of information and mainly over MQTT. Now, Tasmota supports the requested command from the OP in this old issue, that is why we have posted a message in this thread informing that news.
Totally agree. We agree with that from the beginning. That is why, one of the first things we did was to make the Arduino core to support the Wi-Fi and CPU sleep functions to reduce power consumption while allowing the device to be connected at DTIM times. The actual Tasmota is not with the CPU ON and is not with it's Wi-Fi ONLINE all the time. Actually it sleeps and its radio also sleeps. That feature is working fine since several years. In the first Wi-Fi connection, Tasmota talks to the router and they arrange the times where the Wi-Fi Beacon is going to be published from the router and then, in between those, Tasmota sleeps. Those sleeps are very small in order to also be able to be responsive when the user push any button. So, for a smart plug, for example, Tasmota uses as small energy as possible and also it is very responsive from both, your home automation software and from the button. In this type of Setup, the device needs to be Online ( powered from the grid all the time and connected to Wi-Fi too). In order cases, like for example a battery powered plant moisture sensor, Tasmota allows you to use DEEPSLEEP. In this other case, being connected all the time is not needed. The user only needs the data from time to time. In this case, The device is not connected to the Wi-Fi Network. It wakes up from time to time to report its data and receive data if needed (MQTT retained commands for example). In this case, it is a Smart IoT that is not grid powered, that is not permanently connected to the Wi-Fi Network but is able to send and receive information every deepsleep interval.
I think this was a misunderstanding and I did not express myself correctly. Tasmota supports a huge amount of types of setups. It already supports DEEPSLEEP, Some Batery powered devices, turn on and off its Wi-Fi radio, it supports dynamic sleeps and sleeps between Wi-Fi Beacons (and DTIM, meaning to skip some previously arranged amount of beacons), between a lot of features like Rules, Scripts, Berry, Timers, etc etc to make Tasmota behave as you need. It supports MQTT, KNX, Multicast DeviceGroups, Hue and Belkin emulation, MQTT autodiscovery, and several other to interconnect and share information. And much more. It supports to be used in a decentralized system(recommended) and also in a mixed or centralized system (for example all MQTT retained - not recommended and a lot to talk about it). So, it is an amazing firmware for smart home devices. If you want to use as a simple automatic device, you now can too. So, as Tasmota supports all that, your extend to allow MAX17043 for LiPO monitoring for Solar powered devices is in-line with being a Smart Home Device approach and with Tasmota, so I'm sorry if my old comment have made you to think otherwise.
No offense taken. In contrast, it is very good to challenge ideas and put them on the table to polish and to reach a better and more precise understanding. This is the way. |
@thomas-lentz Would you be able to share your code for the Tasmota MAX17043 integration. I also want to use it to learn to do my own integrations. Thank you |
Have you looked for this feature in other issues and in the docs?
yesIs your feature request related to a problem? Please describe.
A clear and concise description of what the problem is.
no
Describe the solution you'd like
A clear and concise description of what you want to happen.
A friend of mine tends to forget to plug off the iron and has to go back to her flat or calls me to check if the iron is plugged off. Therefore I want to preconfigure a Gosund SP111 to power off with 'PulseTime 1900' after half an hour. But I want this to work without a WiFi network available and without Tasmota setting up a hot spot if it finds no WiFi. The hotspot / WiFi should just turn on after long pressing the button or pressing the button several times.
Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.
Rely on WiFi. However this has several disadvantages:
Additional context
Add any other context or screenshots about the feature request here.
(Please, remember to close the issue when the problem has been addressed)
The text was updated successfully, but these errors were encountered: