Open AXYSSA opened 5 years ago
Are you using the Timeprop output?
Yes, I'm
In that case you cannot stop the timeprop algorithm from controlling the output. However if you put the PID into manual using PID_AUTO, which you are I think, then you can use PID_MANUAL_POWER to set the power to the level you want. If you set it to 0 or 1 it will set the output fully off or on. If you set it to 0.5 then it will time proportion to 50%. So you can control the output manually to anything you want.
To stop the button from driving the relay I think you just have to write something to the mqtt topic ButtonTopic. That isn't a PID issue that is a standard feature.
Is there a way to use the PID control without timeprop? If that's the case, I don't really understand the objective of the timeprop output hahaha... So, if I use the PID without timepro, the Timer should work? and the manual mode too?
If you don't define PID_USE_TIMPROP in user_config.h then it won't use it, of course you won't get the time proportioned output on the relay. The pid algorithm will still output a value between 0 and 1 and you can use that to drive the relay yourself however you like. As for the timer, I don't fully understand what you are trying to do. As far as I know there should be no interaction between timers and the pid/timeprop code except that you can't drive the relay if you you are using the time proportioned output. What is wrong with putting the pid into manual and then using the timer to drive the pid manual power as I described? Though I have never used the tasmota timers so I don't know much about them.
Ok, I just make a test with the originals firmwares (without my modifications)
_Using Timeprop, with PIDAUTO = 1 (automatic mode)
_Using Timeprop, with PIDAUTO = 0 (manual mode)
_NOT Using Timeprop ( //#define PID_USETIMPROP )
Configuring a Timer through webserver (with and without timeprop). Turn on the relay in 1 more minute.
I'm trying to make two things work:
You can use last Tasmota with colinl drivers and you can make the timers to trigger a rule. The rule can use the commands PID_AUTO and PID_MANUAL_POWER to use or not to use the PID
Oh, ok, I'll try it tomorrow and let you guys know. Thank you!
Does part 4 work if you use the standard tasmotta s/w without pid or timeprop? If not then obviously this isn't a PID issue. You might get help on that problem on the mailing list/forum https://groups.google.com/forum/#!forum/sonoffusers. By the way, you should have the pid update secs much shorter than the timeprop cycle time. For most applications leaving it at the default value of zero is best, so that it runs the algorithm every time there is a sensor value available.
@AXYSSA is the Sonoff connected to a Pi or something for MQTT etc? If so the way I have done a similar thing is by involving the Pi. I have it so that via my dashboard GUI interface to the pi I can select Manual and control the valve from my phone or PC, but also made it so that a long press on the Sonoff button puts it into manual then a short press on the buttons toggles between On and Off. Another long press puts it back into auto. The LED flashes while in manual with it on blinking off when relay is closed, and off, flashing on when relay is open. Variation of the desired temperature is achieved via the Pi rather than in the Sonoff. I run node-red on the pi (which is great fun to use and has an excellent support forum) which provides the dashboard for all my home automation devices and does the high level control and monitoring.
Does part 4 work if you use the standard tasmotta s/w without pid or timeprop? If not then obviously this isn't a PID issue. You might get help on that problem on the mailing list/forum https://groups.google.com/forum/#!forum/sonoffusers. By the way, you should have the pid update secs much shorter than the timeprop cycle time. For most applications leaving it at the default value of zero is best, so that it runs the algorithm every time there is a sensor value available.
Hello again, @colinl, part 4 works fine with standard tasmota (without PID and timeprop). I checked that to see if the UTC configuration was good. I have set the PID_UPDATE_SECS in 15 secs when it's in automatic (because in the description said that it's well appropriate for a domestic room heating application), and in 1 secs in manual mode. the TIMEPROP_CYCLETIMES is 60. I think it's good enough for a nice work, right?. Anyway this numbers could be change when I make the real proves with the real heater in a room.
Looking again at part 4 above, I see that you are using a timer to switch the relay. That won't work if the timeprop file (xdrv_91_timeprop.ino) is included in the source directory. It is not enough just to remove the #define, which is telling the pid algorithm whether to use it, you must remove the file also.
Looking at xdrv_91 again I can see that it would not be difficult to add a timeprop_enable command to enable/disable the timeprop algorithm completely so you could drive it the way you want to. I would be very happy to apply a PR to add that feature if you wanted to have a crack at it. If you look at how the set power command is implemented you should be able to see how to add an enable/disable feature. I have not got time to do it myself at the moment.
Perhaps the wording on the use of PID_UPDATE_SECS is ambiguous in the description. It says that usually this should be set to 0 to run the algorithm as each process value is received, then suggests that 15 secs may be appropriate. I meant that usually it should be set to zero, and then you should arrange process values to be process values to be available every 15 seconds. That is done with tele_period.
What sort of heater will you be using and how is that heater controlled?
@AXYSSA is the Sonoff connected to a Pi or something for MQTT etc? If so the way I have done a similar thing is by involving the Pi. I have it so that via my dashboard GUI interface to the pi I can select Manual and control the valve from my phone or PC, but also made it so that a long press on the Sonoff button puts it into manual then a short press on the buttons toggles between On and Off. Another long press puts it back into auto. The LED flashes while in manual with it on blinking off when relay is closed, and off, flashing on when relay is open. Variation of the desired temperature is achieved via the Pi rather than in the Sonoff. I run node-red on the pi (which is great fun to use and has an excellent support forum) which provides the dashboard for all my home automation devices and does the high level control and monitoring.
Yes, I have the device connected to a MQTT, so I've been testing MQ communication all the time, but not a Pi, because it's going to run from an android app, and my software college can work better with MQ for that porpuse. I like a lot the idea of a long press on the Sonoff button, that puts it into manual, and then a short press on the buttons toggles between On and Off...
If you SetOption1 to "on" and set ButtonTopic to a string then that should stop the button from driving the relay. When you short press the button it sends an mqtt button message with the value "TOGGLE", and for a long press it sends "HOLD". Then you can use those externally to control the manual operation.
Looking again at part 4 above, I see that you are using a timer to switch the relay. That won't work if the timeprop file (xdrv_91_timeprop.ino) is included in the source directory. It is not enough just to remove the #define, which is telling the pid algorithm whether to use it, you must remove the file also.
Looking at xdrv_91 again I can see that it would not be difficult to add a timeprop_enable command to enable/disable the timeprop algorithm completely so you could drive it the way you want to. I would be very happy to apply a PR to add that feature if you wanted to have a crack at it. If you look at how the set power command is implemented you should be able to see how to add an enable/disable feature. I have not got time to do it myself at the moment.
Perhaps the wording on the use of PID_UPDATE_SECS is ambiguous in the description. It says that usually this should be set to 0 to run the algorithm as each process value is received, then suggests that 15 secs may be appropriate. I meant that usually it should be set to zero, and then you should arrange process values to be process values to be available every 15 seconds. That is done with tele_period.
What sort of heater will you be using and how is that heater controlled?
That would be great!! I just realized (with PID and timeprop) that the Timer is trying to work, at least hahaha, at the moment that I put the "arm" option enable in the webserver (that I don't know what it means...). So now the device try to power on/off the relay, I watch in the "MQTT Lens" the message from the device powering ON/OFF, but inmediatly it toggle to the previous state (OFF/ON)... In the led and in the serial console I could see nothing.
So, I'll try to fix it by myselve, adding a timeprop_enable command to enable/disable the timeprop algorithm, and I'll let you know if I could make it work.
The heater is a wall heater, working by natural thermal convection. Oh! and I will make the SetOption1 advice that you just mencioned.
Thank you so much for the support and all the advices. We'll be talking soon. Greetings!!
In terms of what it has to do I think it is just necessary for it to prevent the call of ExecuteCommandPower
in Timeprop_Every_Second
. Ideally the command should specify which output is to be enabled/disabled.
Once timeprop is disabled, how to PWM drive an SSR connected to GPIO12?
I don't think this question is related to the subject of this issue, however, the PID algorithm will produce a linear value between 0 and 1 that you can use to drive the PWM. I am sorry but I don't know about PWM output. You might be better to ask that on the mailing list.
Hi guys, I'm Felipe, from Chile... I hope you can help me with this issue, I'm new in the arduino/esp8266 and open source/github world... So this is my first time here hahaha...
I have been working with the Tasmota Sonoff firmware, with the PID Control, for make an intelligent heater that you can control from an android app. The objective is to choose in the app between automatic and manual control, so in manual mode I can power on and off the heater whenever I want, or programming some date and hour of on/off, and in automatic mode I can set the temperature, day (s) and hour (s) that you want it to work .
So, the firmware has three things working (Manual mode and Timer in Tasmota, and Automatic mode with PID) but it does not work together. It seems that with the PID control just as it is, the device will work just with temperature control, without the possibility of manual and / or timer control. I did modify the firmware so now I can put the device in Manual mode (direct on / off with MQ command, the hardware button and from webserver), and in Automatic mode with temperature control (PID). Switching the modes using the PID_AUTO command. I also fixed the "bug" of the button in automatic mode. With the original firmware, if you press the hardware button, It'll toggle the relay state for a second, and back to the calculated power state in the PID. With my modification, it do absolutly nothing, wich is better for now...
So, the issue, is that the Timer never work. Not in Automatic or Manual mode. I tryed it with the originals firmwares (without my modifications) and it don't work eather. Is there any "easy" way that I can make the Timer works, independently of the Automatic or Manual control?
Also, a little doubt, wich is the best wificonfig mode for pairing the sonoff with an android app?
PD1: Sorry if my wnglish is not the best, hahaha... PD2: Of course I'll share my modifications when i get it working fine...
Also, make sure these boxes are checked [x] before submitting your issue - Thank you!
status 0
:To Reproduce Use the device in Auto or Manual mode. Send through MQ or through webserver the Timer parameters (for example, power on for 5 minutes in one mode minute)
Expected behavior In any case (Auto or Manual) the Timer work and turn on the led. It doesn't.
(Please, remember to close the issue when the problem has been addressed)