On Hold..

[Oxyandy]

On Hold.. sorry, I may have made an error in judgement on a small detail.. I had not swapped the firmware to the system that has been stable for days, Doing that & re-testing some parts. Guess I was tired & got a bit too enthusiastic.. Welcome to close this.. Some parts of testing I want to start over with different module & a different switch

[TD-er]

But you did describe something of the problem you're seeing. Just a question. The problems you're seeing, are they related to a ESP8285 build? See this piece of code: https://github.com/letscontrolit/ESPEasy/blame/5d41bf9e738655aae146183da050fa0e37b137c1/src/WebServer.ino#L2383-L2423 I've seen this strange line 2412 and it is on my to-do list to look at its implications. It has been in there for a year now (to the date).

[Oxyandy]

When looking at logs of the switch on working firmware I see this:

2018-04-04 13:17:56 | On <- Float SW rises changing from 'closed circuit' to 'open circuit'
2018-04-04 13:17:56 | On <- yeah it reports twice, all firmwares never report once.
(takes float 2 or 3 seconds to lower)
2018-04-04 13:17:58 | Off <- Float SW lowers changing from 'open circuit' to 'closed circuit'
2018-04-04 13:17:58 | Off <- yeah it reports twice, all firmwares never report once.

When it is behaving badly on Dev_12: I see this:

2018-04-07 11:17:14 | On <- Float SW rises changing from 'closed circuit' to 'open circuit'
2018-04-07 11:17:14 | On
(takes float 2 or 3 seconds to lower)-The physical change in the switch still happens at the right time BUT
2018-04-07 11:17:17 | On <- wtf ???
2018-04-07 11:17:18 | On

And this is where it all goes wrong, next cycle GPIO14 is '1' / starts '1' pump turns on, GPIO14 is '1' - fills until reaches switch, switch changes BUT change is NOT logged, because it started '1' there is no change when switch rises and physically changes, so pump is never turned off = firmware fail The rule can not fire when GPIO is wrongly '1' and then changes to the correct '1' (see log above, this IS what is happening) Note while float is up 'open circuit' pump will not stop, if I force the float down, yes this triggers the rule and pump stops. So it does recognise the change from '1' to '0' at the middle part of the OnClock timer, before the OnClock timer has ended, rule says 'any change' in GPIO14 should make GPIO12,0 Please do not forget, I have not yet lowered to Dev_11, these are observations with Dev_12 Now to downgrade to Dev_11.

[Oxyandy]

Almost a conclusion: At least I know, the strange behaviour starts in Dev_11... Dev_10 is ok

Log of float switch in Domoticz, On Clock times 00, 15, .30, .45 (every 15 minutes) using On Clock rule 5 minutes later for off float switch ends that early about 3 minutes after ON time, is a bit different to Dev_12, the GPIO isnt stuck in device page, instead it seems tied to my ONClock OFF about 3 minutes into the 5 Minute OnClock timer, the fluid level reaches the float switch Float rises '1' = ON, 2 seconds later, float lowers '0'=OFF This log is just the float switch.

2018-04-08 05:02:59 | On <- Float SW rises changing from 'closed circuit' to 'open circuit'
2018-04-08 05:02:59 | On
2018-04-08 05:03:01 | Off <- Float SW lowers changing from 'open circuit' to 'closed circuit'
2018-04-08 05:03:01 | Off
2018-04-08 05:18:07 | On <- Float SW rises changing from 'closed circuit' to 'open circuit'
2018-04-08 05:18:07 | On
2018-04-08 05:18:09 | Off <- Float SW lowers changing from 'open circuit' to 'closed circuit'
2018-04-08 05:18:09 | Off
2018-04-08 05:32:58 | On <- Float SW rises changing from 'closed circuit' to 'open circuit'
2018-04-08 05:32:58 | On
2018-04-08 05:33:00 | On <WRONG should be OFF
2018-04-08 05:33:01 | On
(Missing *.45 ON cycle, remember firmware does not log change from wrong '1' to correct '1')
2018-04-08 05:50:04 | Off <WRONG -unexpected time, this is my OnClock OFF
2018-04-08 05:50:05 | Off
2018-04-08 06:02:58 | On <- Float SW rises changing from 'closed circuit' to 'open circuit'
2018-04-08 06:02:58 | On
2018-04-08 06:03:00 | On <WRONG should be OFF
2018-04-08 06:03:00 | On
(Missing *.15 ON cycle, remember firmware does not log change from wrong '1' to correct '1')
2018-04-08 06:20:04 | Off <WRONG -unexpected time, this is my OnClock OFF
2018-04-08 06:20:04 | Off

<WRONG -unexpected time, this is my OnClock OFF (but is stopping stuck '1') No way the switch ever physically moved at this time, the switch movements all happen around 3 minutes after ON time But this log (<WRONG -unexpected time, this is my OnClock OFF)

[Oxyandy]

@TD-er Dev_4, Dev_5, Dev_6, Dev_7, Dev_8, Dev_9, Dev_10 work as expected...... Dev_11 problems starts, all the way through to the most recent fimwares (not tried absolute latest releases as I have been using old firmwares) What next ? Pinpoint fault in Dev_11 & make a working Dev_11 DIFF changes from Dev_10 to Dev_11

[TD-er]

Could you make a summary, as short as possible, describing what's happening and what should happen? Needed:

• Plugin nr/name
• Settings used for that plugin (screenshot?)
• What state change is happening
• What state change is expected.

[Oxyandy]

Yeah ok TD-er.. I hope you can see I am doing my best to supply as much info as possible, something in what I say maybe a clue..

[TD-er]

You are certainly supplying as much info as possible, but at the moment it is a bit too much for me to parse and grasp it all. So maybe if you could summarize it a bit, it will make it easier for me to process it. Something like rubber duck debugging and consider me the duckling on the corner of the keyboard. :)

[Oxyandy]

No plugins really: A Sonoff basic a float switch on GPIO14, as a switch The internal relay on GPIO12 as a switch The last post showing switch log is really a summary, shortened version, when switch changes, it sometimes gets stuck as '1', the next cycle being falsely '1' causes problems (see switch log for better understanding) It is expected that a change in the switch results in firmware changing it state of switch too in other words switch goes from '0' to '1' OK, next change results in '1' to '1', next cycle starts wrongly '1' = problems

[Oxyandy]

Here, this must be GPIO14 starting at correct state, finishing at wrong state.

2018-04-08 05:32:58 | On <- Float SW rises changing from 'closed circuit' to 'open circuit'
2018-04-08 05:32:58 | On
(takes 2 seconds for float switch to lower)
2018-04-08 05:33:00 | On <WRONG should be OFF
2018-04-08 05:33:01 | On

Confused ? So is firmware.. And this does not happen every time.... Although it doesn't happen with older firmwares.. I could try running device on different power source. Reverse switch 180 degrees so it is normally an 'open circuit' - goes closed on rising, returns to 'open' But why does it work before Dev_11, stop working after Dev_11 ??

[Grovkillen]

I've seen this problem with gpio 14 together with switch plugin/task (might be affecting other io as well, don't know). My dehumidifier uses gpio 14 for the relay controlling the pump. I use a task to monitor the state of the relay/pump but the value get stuck on "1" even if pin state page say that gpio 14 is "0". I got it working by using taskvalueset to force the task value to be updated but yes, switch plugin is not working reliable.

[TD-er]

Just to be sure:

But why does it work before Dev_11, stop working after Dev_11 ??

Does dev-11 work?

[Oxyandy]

No, Dev_11 is when this fault is introduced... Dev_10 is OK @Grovkillen - Yes, thanks for your input.. maybe I could try switch on GPIO3, easy swap.. Is this fault specific to GPIO14 ? An answer I could get by swapping, thanks.. I could for my own purposes just use older firmware, but my goal is to make the firmware better, I see a real bug, has taken me ages to 'pin down'.

[giig1967g]

Hi, Can you post your rules, device page, etc. so I can test the same environment too?

[Oxyandy]

The 2 devices pages stitched together

[Grovkillen]

And you have deactivate serial on gpio3? And the button on gpio0 is always high on boot?

[Oxyandy]

Yes, deactivated serial, otherwise GPIO3 can not be assigned. that screenshot was taken when a cycle was active, GPIO 0 is always 0 at boot everything at boot is '0' Low_Res_2, should be '1' cause is empty - Float_SW_2 as '1' is wrong... again Dev_11

[Oxyandy]

And so, earlier I said this:

If problem goes away with Dev_12, I will return to Dev_13, if problem comes back with Dev_13 again.. I will return to Dev_12.. Problem gone with Dev_12 'again', then a report will come ! Otherwise step down to Dev_11 and try that.. Dev_10 is 'confirmed' as not having the problem, so really, really close ;) I will make no dumb or should I say 'rushed' observations Cheers

'Doing' this ^^^^ means my observations are absolutely 'confirmed.. Well should be... If I stick to that. This has been a tough problem to absolutely 'pin down'...

[Oxyandy]

2 systems, 6 hours+ running Dev_10 and both doing fine.. I need to go away in a few days for 5 days & these 2 systems have plants.. That gives a bit of time to confirm stable before I leave for a mini holiday.. Back next weekend, no more posts from me says "All OK !" Dev_11 doesn't last this long before failing.

[giig1967g]

Hi @Oxyandy, I have 4 comments: 1) Please send your config file, removing passwords. 2) How can you disable serial (to use GPIO3)? 3) Is this rule correct (you set gpio,12 to 0 in both cases):

on Float_SW_2#switch do
if [Float_SW_2#switch]=1
gpio,12,0
publish domoticz/in,{"idx":49,"nvalue":0,"svalue":"Float_SW_2_1_%systime%"}
else
gpio,12,0
publish domoticz/in,{"idx":49,"nvalue":0,"svalue":"Float_SW_2_0_%systime%"}
endif
endon

4) I am not sure if this is yours case too, but my experience is that since version 2 (but could be dev10 as you say because I joined at dev12), if you use the switch plugin task as a Output it eventually crashes. Probably because as the plugin name says - SWITCH INPUT - the plugin is supposed to control INPUT only and not output. I have opened several forum requests, but found no solution. So I ended up using a Dummy task to keep trace of the status of the OUTPUT pin, as suggested also by @Grovkillen . That is rock solid.

[Oxyandy]

1. config.dat.zip

2. 

3. Yes, my Float Switch is meant as an OFF only. So it was a very simple rule, but because of issues, I added extra to report the state of GPIO14 to a custom log. And want 'any change' in the Float Switch to only turn off, never on the extra gpio,12,0 never helped, but did no harm so was left there :)

   on Float_SW_2#switch do
   if [Float_SW_2#switch]=1
   gpio,12,0
   endif
   endon

4. I have no experience with a "Dummy Task" yet, any examples ? Cheers

Update***Dev_10 running on 2 different Sonoff Basics, just checked uptime 23 hours**, tank levels are as they should be, there has been no overflowing. 👍

[giig1967g]

Hi @oxyandy I haven't been able to run your firmware, as I couldn't change the IP address (probably because the serial port is disabled... or maybe AP is disabled...)

As I understand, you have three INPUTS (GPIO14,3,0) and one OUTPUT (GPIO12). If so then try this: a) delete task number 4 (the GPIO12) b) add task number 7 as a DUMMY device, as per image attached (but keep task number = 7) c) modify the rules as per attached file: rules.txt d) reboot, doing a power off cycle. e) should work :)

[Oxyandy]

Excellent, I had been meaning to look deeper into events, that example just makes it super clear for me to understand ! Yes static is set, http://192.168.0.200 I did try to delete those values, but I see a bug when I do - old dev_10 and yeah without serial enabled you can not push commands via serial console.. To get WiFi access, I set WiFi SSID TEMP PASS 12345678 Serial is enabled, GPIO3 disabled config.zip

[giig1967g]

Try my suggestion first. If it doesn't work I will try to load your config.

[Oxyandy]

Rules2

on Float_SW_2#switch do
if [Float_SW_2#switch]=1
gpio,12,0
taskvalueset,7,1,0
event,pump2switch
publish domoticz/in,{"idx":49,"nvalue":0,"svalue":"Float_SW_2_1_%systime%"}
else
gpio,12,0
taskvalueset,7,1,0
event,pump2switch
publish domoticz/in,{"idx":49,"nvalue":0,"svalue":"Float_SW_2_0_%systime%"}
endif

Maybe I am not understanding this right ? But [Float_SW_2#switch] is my GPIO14, if I delete that how is the switch going to trigger ? GPIO0 is the button on the Sonoff, manual on/off of Relay GPIO12 GPIO3 is just a sensor for "Low Fluid Level", and for the moment not used.

[giig1967g]

Delete task number 4, GPIO 12.

[giig1967g]

@Oxyandy : did you try dev11 with my rules and suggestions?

[Oxyandy]

try dev11 with my rules

Looking at the rule, I see that GPIO14 will still get stuck, it is a great example & teaches me something new. I tried a similar thing before & it did not work. I will try your rule, but have run out of spare time, when I return it will be the first thing I do... But I need to be here to watch it's impact. Dev_10 works, so while away it will take care of things. I am not going to be online or be able to test anything until Saturday..

[giig1967g]

Hi @Oxyandy , the reason why it is important to test my suggestion is try to limit the issue to something more specific. In other words, if with the new rules and suggestions (delete the OUTPUT task, create a dummy device, etc...) the problem is gone, then the developer can concentrate on a specific behaviour of the plugin, saving time. Please make this test and report.

Also, which is the more recent firmware version you tested your unit with?

[giig1967g]

@Oxyandy : if rules3 is too long, split them into rules4.

[Oxyandy]

On my own long and complex review of what I was experiencing with a switch on GPIO14 and yes Domoticz MQTT controller, I tracked an error back to beginning with Dev_11. #1216 I have tested versions prior to Dev_11 all the way back to Dev_4 & those all work just fine. Versions Dev_10 & prior have proven stable over days on end, Dev_11 fails quickly Something changed between Dev_10 & Dev_11 and a bug was introduced. A bug which was is still present in very recent releases (not sure if still present in very latest firmwares) Are these all related #673 #674 #675 #924? I created an archive to help Inside are only the changed files from Dev_10 to Dev_11, all renamed in the format below to make the origin of each file perfectly clear - Extract contents of this archive to a single folder

_P029_Output_Dev_10.ino _P029_Output_Dev_11.ino

With a visual text compare tool. Selecting both versions, compare... If someone has the time ? Maybe something stands out ? Dev_10 works, Dev_11 the problem started.

CHANGED_v2.0.0-dev11.zip

[TD-er]

Can you summarize in just a few lines what is happening and what should happen? So what plugin, what plugin config (screenshot?) and what is connected to this GPIO. And what should happen and what does happen?

[Oxyandy]

Yeah @TD-er, I guess I could read over everything I have posted here, Open a fresh "Issue" trying to keep everything minimal.. The whole thing is much clearer to me now than it was when I started looking into this

[TD-er]

Clarity is always nice when describing issues :)

[Oxyandy]

In my attempt to make it 'Repeatable' - in the simplest form I am down to just one device & one controller running Dev_11 Configured LED & Wifi, otherwise default too That is where I was up to before I could not longer stay awake.. Seeing if I can simply it even further now awake a few hours later