The valve gets sort of stuck after some time, getting the commands but it is like frozen (which for a radiator is not good at all! HA HA HA!)

[Anycubic]

After hours running fine in heat mode, in one radiator measured temp was keeping increasing like if the valve was dead. Lowered temp by 2 degrees and the valve not reacting. Shut off command was issued but still no noise from the valve. Recycled the power and I heard the valve closing eventually.
Going to serial log ...

[alexmohr]

how long did the valve work after the reset?

[Anycubic]

I'd say 2-3 seconds

[Anycubic]

For sure it wasn't stuck at full open position

[Anycubic]

It was closing-opening a few hundreds millis each time, than started to open and got stuck (the code, not the physical valve)

[Anycubic]

It must be something really tricky because the other one is going great:

[alexmohr]

It probably drifts appart because there is a (small) time between setting the GPIOs and the motor actually spinning.
Maybe always adding a small time to the valve operation, say 10-20ms or so would help.

[Anycubic]

But how does it come that motor didn't spin at all when I issued mode = off? I was there trying to listen with my hear close to the valve :-D

[Anycubic]

BTW my test rig is up and running, tomorrow I will serial log all the day long

[alexmohr]

I won't be able to do things for the next couple of days so take your time logging.
The motor does not spin because the software assumes it's fully closed already.

[Anycubic]

I see, if in theory is possible that in a few hours it spinned so many seconds then it could be an explanation, though I can't understand why the other one run all of the day long without a single issue. Hope you are going on holyday!

[alexmohr]

I wish I would 😆
I don't really have an explanation why to be honest. I doesn't happen to my radiator either.

[alexmohr]

I've added a spin up time of 25ms in the old_regulator branch. Please use this for your tests :)

[Anycubic]

Ok, I'l do it tomorrow ;-)

[Anycubic]

Tonight I was thinking... Let's assume the valve THINKS it's closed but it's not...so why don't you add a safety check like

I'm (the valve) think I'm full closed but after 3/4/whatever regulator cycles temperature is actually INCREASING
-> I'm not really closed
-> issues a 5/7/whatever seconds closeRotation command
-> check again after 3/4/whatever regulator cycles -> temperature decreased eventually? Ok now I'm really full closed, let's resume normal operation from closed position
-> temperature is keeping on increasing? -> I'm probably broken (motor or temp sensor) let's issue a full closeRotation command, shut off and send an error message e-mail

What do you think? I need to sleep more? Yes you are right!

[Anycubic]

Wait! It happened also to the other valve (didn't had it patched with last commit yet). Power cycled -> switched on and closed for about 5 seconds

[Anycubic]

And BTW after a cycle of off-heat-off I'd close the valve 5 seconds or so MORE than the regulator calculated, just to take into account jitters/mechanical imperfections. Yes, I know the real solution is always the same, being able to detect the close valve position

[Anycubic]

It probably drifts appart because there is a (small) time between setting the GPIOs and the motor actually spinning. Maybe always adding a small time to the valve operation, say 10-20ms or so would help.

Maybe there is another factor: when you give the start impulse the motor will not start spinning at the moment "0" but some millis after (due to mechanical factors there is a transient period). So it will rotate each time a little bit less that it is supposed to be and so movement by movement will go out of synch eventually.

[alexmohr]

That's exactly what the

It probably drifts appart because there is a (small) time between setting the GPIOs and the motor actually spinning. Maybe always adding a small time to the valve operation, say 10-20ms or so would help.

Maybe there is another factor: when you give the start impulse the motor will not start spinning at the moment "0" but some millis after (due to mechanical factors there is a transient period). So it will rotate each time a little bit less that it is supposed to be and so movement by movement will go out of synch eventually.

That's exactly what the latest commit tries to compensate. 25ms are rotated on top of the given time.

[Anycubic]

I see, I thought that those 25ms more were meant to compensate electric transient only. I have the feeling we need to double if not more that number... will it be too time consuming adding a MQTT topic with total number of movements (close+open) done in an entire heat -> off cycle?

[alexmohr]

50ms would be the maximum as it would affect the regulator too much otherwise.
For what do you need the topic?

[Anycubic]

When the valve goes crazy I will approximately calculate how many seconds was out of synch/numbers of activation = average milliseconds * activation of transient to be taken into account. I'll do it until we will ALMOST solve this issue. Will it work?

[alexmohr]

Can't you just take that from the serial log? Should be a simple grep. was the 25ms not enough?

[Anycubic]

Is what I'm trying to do, just saying that should I find the sweet spot now, with that number will be easy to tweak again in the future without having to log one day long 😉

[Anycubic]

was the 25ms not enough?

So far so good, BUT now I can see fluctuation that were not spotted before. I wonder if now with those 25ms the algorithm is really showing itself so that it will be easier to fine tune it once for all

[alexmohr]

Adjustment of close time should fix this but let's wait if this fixes the closing issue

[Anycubic]

I'm attaching 7 hours of log. At the end it seems that the valve jittered "only" 700ms as per last off operation (actually after power cycling the valve really closed for less than a second).
Also the other valve with the new code was almost spot on, same beahaviour.

If I'm not wrong 700milis/43 valve movements = approx 16 millis on top the 25. Btw even if the adjustment value is correct I still think that last off command should close the valve a little more than the theoric value, in a way or another there will be always a little jitter (i.e. motors are not exactly all the same).

I also saw a lot of "Minimal sleep or underflow prevented, sleep set to 10000l ms". Why so many and why sleep set to only 10000 ms? Of course the battery isn't going to be happy.

What do you think?

teraterm.log

[alexmohr]

This won't be ever fixed properly with the current hardware.
The jitter varies from valve to valve because the motor spin up time depends on the necessary torque which depends on the valve (and probably also the current motor position as a valve which is closed further requires more torque to close fully)
that's probably why both your valves differ and I had never such an issue.

It would be possible to just add 50ms and things might work or less if we adjust the regulator. Rotating an additional second in the last close operation before reaching the limit can be more or less easyily.

The minimal sleep prevention happens of the Mqtt sleep time is a multiple of radiator sleep time.
Instead of sleeping only a few milliseconds it just sleeps 10s. This is to make sure we turn the WiFi off before running the next loop.
For example if the radiator sleep is 0 at the end of the mqtt loop the device would sleep until an external reset is triggered.
This is prevented by the underflow prevention.

I haven't checked the logs yet but I will take a look in the next couple of days.

[alexmohr]

• Increased spin up time to 50 ms
  • open/close will take spin up time into account to prevent fluctuation
• Add 1s long turn time when limits are reached

[Anycubic]

Flashed on 4 valves ;-)

[alexmohr]

it's still not solved. Turning off just rotates the valve for the 1s I've added as additional time, but after resetting it's still open a lot. 2-3s after 2 days or so of being open. Maybe the 50ms are not enough. I'll try doubling it but I don't think it will solve this.

I got the hardware to implement a stop detection, but this will take a lot of time to develop and test the circuit and the software for it.
At the moment I neither have the time nor the motivation to do this. Maybe in the holiday season but at the moment it looks more like I'm going to drop the project altogether and just buy something that works already.

[alexmohr]

I don't get where the difference is between 1 and 2. It is most likely the same reason where the time measurement is off to some reason. Instead of stopping to close when the time limit is reached you could somehow measure current of the motor and only do open time base.
But when you do this you'll probably have the issue with opening sooner or later.

If you don't care about battery lifetime too much you can just remove the check for the lower limit and just always rotate when you close.
Maybe it's worth a shot to test this to really pinpoint the issue to the time measurement.

isReallyClosed should also be done by detecting if the motor is stalled.

I'm not abandoning this project (yet) but I really don't have the time to do any coding on this at the moment due to a multitude of personal reasons. I'm doing this thing in my free time and there is just not enough of that as even my weekends are fully booked.
Asking over and over again for suggestions and solutions is not going to change that, sorry to be blunt here...

The main reason why things INA219 are not going to work out of the box is that you have to power the motor through the module. See https://learn.adafruit.com/assets/10941
You need at least a diode to protect the INA219 against reverse polarity.
Then you'd have to turn on the module when closing with a gpio to prevent drawing current all the time.
Furthermore you need a capacitor to smooth the current consumption of the motor at spinup.

To cite adafruit here:

Be careful inserting noisy loads that can cause a sharp current draw, such as DC motors, since they can cause problems on the power lines and may cause the INA219 to reset, etc. When using a DC motor or a similar device, be sure to include a large capacitor to decouple the motor from the power supply and use a snubber diode to protect against inductive spikes.

So it's not as easy as wiring up a BME/P module and needs at least some engineering.

The circuit I have in mind is not easier but it works in both directions.

[alexmohr]

An alternative circuit is the one below and that's the one I'll try first as I have all parts for that.

[Anycubic]

I don't get where the difference is between 1 and 2. It is most likely the same reason where the time measurement is off

Actually there is no difference, you are right. The only different thing is when it happens: 1 it happens while heat is on (so needs to be checked during normal operation every time the valve thinks reached the off position). 2 it's not a real problem, just closing with stall detection will be fine.

to some reason. Instead of stopping to close when the time limit is reached you could somehow measure current of the
motor and only do open time base. But when you do this you'll probably have the issue with opening sooner or later.

That's exactly what I want to accomplish 😉

If you don't care about battery lifetime too much you can just remove the check for the lower limit and just always rotate when you close. Maybe it's worth a shot to test this to really pinpoint the issue to the time measurement.

You mean without measuring motor current just force let's say 20000 millis close rotation when the valve thinks "I'm already closed do not rotate anymore"

isReallyClosed should also be done by detecting if the motor is stalled.

Of course otherwise will be useless

I'm not abandoning this project (yet) but I really don't have the time to do any coding on this at the moment due to a multitude of personal reasons. I'm doing this thing in my free time and there is just not enough of that as even my weekends are fully booked. Asking over and over again for suggestions and solutions is not going to change that, sorry to be blunt here...

Worry not! I fully understand

Then you'd have to turn on the module when closing with a gpio to prevent drawing current all the time.

I was thinking to use GPIO 13 in parallel with BME/BMP

To cite adafruit here:

Be careful inserting noisy loads that can cause a sharp current draw, such as DC motors, since they can cause problems on the power lines and may cause the INA219 to reset, etc. When using a DC motor or a similar device, be sure to include a large capacitor to decouple the motor from the power supply and use a snubber diode to protect against inductive spikes.

Now that's indeed interesting. There are also other modules, like this one with 3 channels, I'll have a look at tech specs as well

https://www.aliexpress.com/item/32828796768.html?spm=a2g0s.8937460.0.0.509d2e0eYxa8ch

EDIT: I need at least two of these because this board actually powers the devices that is measuring. BUT with 2 diodes it should work, one board powers the motor while closing and the other one with reversed polarity will power while opening.
EDIT 2: because the 2 modules will be plugged to GPIO 12 and 14 this will also solve power consumption issues.
Will it work?

So it's not as easy as wiring up a BME/P module and needs at least some engineering.

The circuit I have in mind is not easier but it works in both directions.

I think understanding it is beyond what I can do. What I can do is ordering the PCB if I have a layout and soldering the components 😄

[alexmohr]

Why a 3 channel module? That makes it only more expensive but you only need one

[alexmohr]

If you do the (tedious) work of finding a matching module I'll order it too 'cause it's probably (much) easier than my suggested circuit.
fyi if you are interested in a turn off button you can order https://de.aliexpress.com/item/1005003027936356.html?spm=a2g0s.9042311.0.0.1d9d4c4d1pAUmj CD4043BE . It's the same SR-Latch I've ordered for the reset button. Or you wait until I've implemented it.
Have you made any progress on your case cad?

[Anycubic]

Don't know why but you can find it only with 3 channel. BTW it is 1,62 € each, circa 3€ for each valve. If you consider all of the time and material you save instead of making an ad hoc board....I'd say it is very cheap.

So do you think it will work? If the answer is "oh yeahh!" I'll ask you only a wiring diagram on how to connect them, were to put the diodes and maybe a capacitor (or 2?). Than I'll order the pieces and will start assembling a prototype + measuring current in a real environment

[Anycubic]

fyi if you are interested in a turn off button you can order https://de.aliexpress.com/item/1005003027936356.html?spm=a2g0s.9042311.0.0.1d9d4c4d1pAUmj CD4043BE . It's the same SR-Latch I've ordered for the reset button.

I think i can afford it, I'll buy them 😄

Have you made any progress on your case cad?

Unfortunately not, I didn't start yet, all of my time was spent in debugging the valves. But my next priority is the case, the one I'm using right now is, how can say, too fragile? 🤣

[Anycubic]

....and btw I think I found another reason why the valve will go intrinsically out of sync. Measured closing time is approximately 40 seconds, full opening just 37. That's not surprising at all since while closing it has to counteract a spring force and while opening the same force on the contrary will help the motor spinning.

[alexmohr]

....and btw I think I found another reason why the valve will go intrinsically out of sync. Measured closing time is approximately 40 seconds, full opening just 37. That's not surprising at all since while closing it has to counteract a spring force and while opening the same force on the contrary will help the motor spinning.

That's actually quite a good reason why things are going out of sync.

So do you think it will work? If the answer is "oh yeahh!" I'll ask you only a wiring diagram on how to connect them, were to put the diodes and maybe a capacitor (or 2?). Than I'll order the pieces and will start assembling a prototype + measuring current in a real environment

Before measuring current there is some software necessary. You can write a prototype but the currents for "normal" operation are arround 15mA and for "locked" arround 40mA so there is not that much measurement necessary.
I'd go for the INA219 but I first have to make a schematic to see if it really works. Maybe I get around to do it on sunday or so

[alexmohr]

The case I designed isn't too bad just a bit too small

[Anycubic]

the INA219 but I first have to make a schematic to see if it really works. Maybe I get around to do it on sunday or so
Ok, np, I'll wait, take your time

[Anycubic]

The case I designed isn't too bad just a bit too small

Am I wrong or the batteries are not in the case? 🤔

[Anycubic]

Out of curiosity, these are 3 of my valves today. 2 of them closed 100% at off mode, one didn't but was almost there. So I guess it's up to valve spring force and the other mechanical factors.
In general I'd say the regulator algorithm works very well.

[Anycubic]

Interesting, 7 Sensors tested: Measuring Current with Microcontrollers
https://www.youtube.com/watch?v=cG8moaufmQs&ab_channel=AndreasSpiess

[alexmohr]

The case I designed isn't too bad just a bit too small
Am I wrong or the batteries are not in the case? thinking

They are mounted below

The graphs look great I even have less fluctuations than you

The INA3321 has the abitilty to switch a channel off.

Channel enable mode. These bits allow each channel to be
independently enabled or disabled.
0 = Channel disable
1 = Channel enable (default)

https://github.com/beast-devices/Arduino-INA3221/blob/main/Beastdevices_INA3221.cpp#L261
So I guess one module could be used to measure both directions and only the required channel will be enabled.
I'm not 100% sure this also means the output is disabled to I read the datasheet like that

Maybe you can take a look too and tell me I'm correct 🤣
https://www.ti.com/lit/ds/symlink/ina3221.pdf?ts=1638920630869&ref_url=https%253A%252F%252Fwww.ti.com%252Fproduct%252FINA3221

[Anycubic]

They are mounted below

I see but my 4 years son would take them apart in 1, 2, 3 seconds 😄
I'm going to try to put everything in a box

The graphs look great I even have less fluctuations than you

Consider than my temp sensors are in the "open air" so there are also micro fluctuations due to just me passing by a radiator

Maybe you can take a look too and tell me I'm correct 🤣

In theory this is correct 😛 but those chinese boards are limited to only one input voltage bus BUT there is a solution:

https://www.youtube.com/watch?v=EjGhbiudRgg&ab_channel=RobotPad

So yes, if we modify the board it should be possible using only one board. The Expert (me) said it! 🤣

[alexmohr]

https://www.youtube.com/watch?v=EjGhbiudRgg&ab_channel=RobotPad

That doesn't look too bad. I'll order one

[Anycubic]

If I were you I'd order at least 2, with chinese goods you'll never know...I'll do the same

[Anycubic]

What about diodes? I need to buy them as well. I have some capacitors at home but don't know if I have the right ones

[alexmohr]

If I were you I'd order at least 2, with chinese goods you'll never know...I'll do the same

yep done that :)

What about diodes? I need to buy them as well. I have some capacitors at home but don't know if I have the right ones

Any diode will do, I won't recommend one until I've tested it with them. There is no specific requirement. They are only necessary to protect the ina from input voltage through the motor.
Same goes for capacitors any electrolyte capacitor will do. Maybe around 100uf or so

[Anycubic]

How are you? Just to let you now I bought everything needed and waiting for delivery

[alexmohr]

Same here. We are in the process of moving and I packed up all my electronic development stuff so it will take a while until I've set up my workbench again 😅

[Anycubic]

I see, so in the future new radiators to work with! 🤣 I went back to old "dumb" but working valves, in the meanwhile I'll focus on the case in my spare time.

Happy moving! 😉

[Anycubic]

Hello! How are you? Everything ok with your move? Today I received 4 of these babies, it seems they are the modded version (3 independent inputs):

[alexmohr]

That's awesome. I've received mine too already but they are still packed up. Probably it will be summer until I've set up my workbench and can work on this again. :(

[Anycubic]

Well, at least they will be ready for next winter! 😂

[Anycubic]

Now I'm 100% ready 😉

[Anycubic]

Hello Alex, how are you? Are you going to work on this project again? I really hope so

[alexmohr]

I'm currently not working on it, because I don't have enough time to spare for this project. I do plan on finishing it somehow eventually

[Anycubic]

Ok, great news by the way. In the meanwhile, in order to bypass the out of synch problem, I was thinking to implement a really quick and dirt solution: using just full opening and full closing the valve. I know, this is blasphemy for you, but I think that in this it is going to work 100%