lenti84 / vdmot_controller Goto Github PK

Can we add a Option to turn off the LED's in the 2 Boards. The blinking LED is really bad if you dont use the board in a Case.

Uptime wird nicht per MQTT gesendet oder in Abständen die ich nicht nachvollziehen kann.
Am Anfang wird es einmal gesendet dann nicht mehr aktualisiert.

Hi! Thanks for this great project!

I have 13 valves to control. Would it be possible to squeeze in control for an extra connector (or two, to make the number even)? Or maybe add support for an extension board? 😬
I know this might be a big request, but I had to ask :)

Originally posted by @nstadigs in #2 (comment)

Have 14 sensors connected.

Only sensors with number <= 12 are published, if they are not asigned to a valve.
( same for GUI status, JSON /temps and MQTT /VdMot/temps/. )

Plus the GUI sensor numbering in "/status/Temperature" and in "/config/Temperature sensor" have different numbers for the same sensor :-(

Sensors with Numbers > 12 can be asigned to valves, and shows up correctly there.

change proposal

I would opt that the /temps publishes ALL temperature values, not only the not asigned sensors. It is very hard to know for an external home automation system which sensor has which function. Plus the asigned sensor data vanishes, if the sensor is not there at boot, the not asigned sensors are found again at later time.
Kind regards
Alfred

Hi.
Do you have any Idea which cable length is possible between the Controller Board and the actors?

Could please explain the meaning of some of the fields in the Control and in the Config section?

Control page:

• What does Xp, Offset, Ti, Ts mean? I guess Ti and Ts are the parameters of the PI controller, but the rest...?
• What is the difference between dynamic ki and static ki?
• How can I determine the Active zone? Do I need to extract the current values for, as in your measurements for the two different valves?
• What does happen in the manual heat control mode? Is Xp the dedicated position for that?

Config page:

• What do the Characteristic values in the Motor section mean?

This is a feature request, so feel free to flag it accordingly.

This is related to #73 : It would be desirable having an option to leave all valves at their current position when disabling temperature regulation (i.e. maintopic/common/heatControl set to 2 (Off)). This avoids unnecessary travel and therefore noise and wear of the valves.

This could be a boolean flag/check box in the UI.

Thanks and regards
EW

My Controller disconnect from WLAN if it is running longer. Only a hard reboot reconnect to the Router.
It was on Version 1.2.2 Dev.

I try to find out how long it need that the controller disconnect.

I updated to Gargano 1.25 Dev hope this helps

Status page should display current state of the state machine, especially

• if the control is Manual, On or Off currently
• current tValue/tTarget temperatures when used with MQTT

This will help a lot to debug systems and verify the setup.

Cooling function should invert the logic of the pi controller

Hello togetherness

I have a questions please

Is it possible with the current software to receive the setpoint temperatures of each room via mqtt?
Also the ACTUAL temperatures?

I would install in each roomt an ESP32 as a thermostat which sends the set and actual temperature via mqtt to the software.

greetings
zillawilli

Hallo Miteinander

Ich habe bitte eine Frage

Ist es mit der momentanen Software möglich, die Soll-Temperaturen der einzelnen Räume über mqtt zu empfangen?
Ebenso die IST-Temperaturen?

Ich würde in jedem Raumt einen ESP32 als Thermostat einbauen welcher die Soll- und Ist-Temperatur per mqtt an die Software sendet.

schöne Grüße
zillawilli

Hi I‘m wondering if there could be a esp32 with Lan possible on the board? Thank you for your help

Greetings Thomas

I'm only opening an issue because discussions are not enabled.
I ordered 2 vdmot to play around and tried one of them on my distributor.
I'm not familiar with various distributor or valve types, mine is open (full flow) when the needle is not pressed in (default). The wax valves are pushing them in in cold phase and when heated up the wax expands and releases the pressure.

So my issue is that in my case I can not really identify anything from current measurements. (vdmot top=fully retracted)
Here is a valve closed (vdmot at bottom going top) -> opening sequence:

The case of the valve is fully opened (vdmot starts from top position) -> close:

If I see it correctly in you case the vdmot push pin has a play/gap so you have a freewheeling ~18mA phase, then a contact period, and a definitive section where the pin is pushed all the way in.
I guess you also can't tell when the flow starts/stops just from end positions of the motor?
I also found that there is a huge "hysteresis" between opening and closing when microstepping the motor with 20-50ms impulses.

Also funny how much smoother your current measurement is, I used the PPK2 from nordic. You can literally see the commutation:

Hello,
asembled the kits last weekend, but could not compile via VSC Platformio. (C++ errors )

Could you please add the additional needed BIN-files for flashing the ESP32, so that I can use esptool.py without compiling?
(or did you pack all the files into your firmware.bin, so I could upload to address 0x1000 ?)

e.g.

esptool.py --chip esp32 --port COM4 --before default_reset --after hard_reset write_flash -z --flash_mode dio --flash_freq 40m /
            --flash_size detect /
            0x1000 bootloader_dio_40m.bin  /
            0x8000 partitions.bin /
            0xe000 boot_app0.bin / 
            0x10000 firmware.bin 

Erasing is working so far, so the system looks OK..

esptool.py --port COM4 erase_flash
    esptool.py v2.8
    Serial port COM4
    Connecting......
    Detecting chip type... ESP32
    Chip is ESP32D0WDQ5 (revision 1)
    Features: WiFi, BT, Dual Core, 240MHz, VRef calibration in efuse, Coding Scheme None
    Crystal is 40MHz
    MAC: 8c:ce:4e:94:82:dc
    Uploading stub...
    Running stub...
    Stub running...
    Erasing flash (this may take a while)...
    Chip erase completed successfully in 14.0s

Thanks for your help
Alfred

202206071941_VSCcompile.log

Hi,

can you provide some information on how to order and costs?

I updated the WT32 to Verson 1.2.5 Dev it works. But for the STM it show after the Update the last Version 1.2.2 DEV. I have a C1 Board.

The Update is working normal and show Finished. ?????

Thanks.

Since I did not find another way for contact.

1. What's the power consumption in "standby" so when no motor is moved?

2. Do you use all 4 wires of the VDMOT? I read something that two wires are for the motor and the other two can be used for better positioning?

3. Did you also think about a possibility to connect this to KNX? (currently I do not have LAN there, but KNX 😄 )

Same behavior with 1.0.7 and 1.0.8 - here's the backtrace:

[...]
pop gvlon 255 
pop gvlst 
Reconnecting MQTT...

Stack smashing protect failure!

abort() was called at PC 0x400ef5d4 on core 1

Backtrace: 0x40082fe1:0x3ffb1fc0 0x4008d33d:0x3ffb1fe0 0x40091f8d:0x3ffb2000 0x400ef5d4:0x3ffb2080 0x400d91b5:0x3ffb20a0 0x400d950f:0x3ffb2150 0x4015855b:0x3ffb2170 0x400de261:0x3ffb2190 0x400d9982:0x3ffb21d0 0x400d7eb6:0x3ffb21f0 0x400d8336:0x3ffb2210 0x400deb9b:0x3ffb2230 0x400de8fa:0x3ffb2250 0x400d8d26:0x3ffb2270 0x400e8d61:0x3ffb2290

ELF file SHA256: 0000000000000000

Rebooting...
VdMot_Controller
Start Config
SPIFFS booted
get file : STM32_C2_firmware.bin
Interface type 0
Setup Eth 0
Server started 0

ETH Started
Setup Wifi 0
Interface type 0
Setup Eth 1
Server started 0
Setup Wifi 1
[...]

It runs for some seconds and crashes again most probably on "Reconnecting MQTT". This device runs on WiFi.

I had the same problem yesterday evening. It may be an coincidence or not but it seems only to happen in the evening/night on this device - so perhaps it's related to some date/time code. If I'd have to name a time: I have discovered it around 22:00. But take this last paragraph with a big grain of salt.

Of course the status page goes nuts:

Looks like a severe case of memory corruption or an insane memory leak which reaches the stack after some seconds.

Some sensors are not detected by scan, others detected but no data.
GUI/config scan gives different results to the scans when booting.
Some sensor delivers data, if manually eintered ID in GUI/config

All sensors are tested and working with ESP PIN and 4k7 Ohm resistor.
Sensor answer is on the bus, but not picked up to i2c?

Signaling on oszilloscope comparing ESP and VdMot looks ok.

Logic compare "-22" sensor detected, but no data,

ESP test sample OK

VdMot

Logic compare "a9" sensor not detected

ESP Test sample OK

VdMot test

Hallo,
habe von deinem Projekt im FHEM Forum gelesen.
Das wäre genau, was ich mir für meine Deckenklimatisierung als Steuerung wünsche.
Die ist nicht so träge wie eine Fußbodenheizung und braucht ordentliche Regelung, nicht nur 0/1.
Daten der Wärmepumpe, VL/RL und Thermostate habe ich schon in MQTT.
I2C fur HTU21D ( Humidity/Temperature -> Taupunkt im Verteiler ) würd ich am ESP dazubauen... ( die Onewire DHT22 sind Mist bei 100% Feuchte )...
Wenn du Prototypen/Kleinserie machst, beteilige ich mich gerne an den Kosten und würd 1 zum testen und ggf. 3 Stk für Echt nehmen
danke+lg
Alf

I don't have your board or debugged the code just went through the schematic and the codebase.

Assuming I issue a few steps of open/close to the motor 1000-100000x would'nt this approach lose the correct position after a while?

I'm assuming the rotor counter works to a certain speed (amplitude gets lower) so at lower speed this loses the steps which I believe negligable (?) effect if motors are operated in ON/OFF mannger.

But also the ISR quits counting right when reaching the target, any DC motor in my experience will still rotate in freewheeling mode (don't know how much here we are talking about but the error will be accumulated). Now i'm certain it wont be simmetrical in both ways so this counting up/down will eventually cause a drift error in the step following.
Would'nt it be more precise to wait till the ISR/tacho impulses "ramp down"? Once target is reached the counting continues for 100-500ms you would have more accurate position tracking.

If I saw it correctly the opening and closing states detect endpositions thus sooner or later this would be noticed.

Hi all,
I can set the station name via GUI.
How can I query the station name via JSON/API?
Would have expected this under /netconfig.

Have multiple controllers and want to automate Homeassistant Integration.

Thanks
Xal

I just discovered a strange behaviour:

I wanted to lower the current opening percentage of tht valves. control is on, but the temperature is almost there but the valves were still at 50% because this device crashed (I learned though that manual entry doesn't affect the control loop though).

Valve 1 is the main valve, all others are linked (slaves).

When I set now set all the new values to 10, every valve except for 2 (the first slave) got set to the new value. This got me suspicious: When I now change only the first slave it affects the second slave.

There is no way to set the first slave. It looks like the indices are messed up when linked valves are involved.

I tried to capture it in two comprehensible screen shots:

Hello,
Usecase: 8 Valves, 10x Onewire sensor ( one for each valve, plus one for manifold input and output )

• How will this look like in the status page ?

• Config page needs a mapping from Onewire_ID to Name and valve
  STM32 command list ist talking of 36 possible Temperature sensors
  stsnx x y: | set first 1-wire sensor index y to valve x | x=0...11, y=0...35

  And why are there 2 commands [ stsnx | stsny ], as there is only one 1-wire bus?

Thanks, and keep up your great work
regards

After Update to DEV 1.2.3 i cant see the MQTT Values (tTarget, tValue) on Status Site on DEV 1.2.2 i see without issues.

Great to see some updates :-)
What I would like to have is an option to enter calibration values for the Onewire temperature sensors.
My temperature range is 15-32 deg Celsius ( cooling/heating )
If I have a bunch of DS18B20, I can see values +/- 1,5K. No need to meet the exact temparature, but all sensors should have the same base temperature, even when a little bit wrong.
Simple linear regression formula ( y= kx+d) with a way to enter the k,d values per sensor would help - otherwise I would do that in the MQTT server.
Gold star solution to have an auto-calibration mode. Run once when the whole system is OFF and its cold ( e.g. 15°C), store the values), same when distribution cabinet is hot ( 35°, and all OFF for a while ). Then do the mean values and calc the regresssion.
Cheers Alf

Originally posted by @xal88 in #2 (comment)

Is there a RJ45 Network available ?

Some has changed in SPIFFS 2.0. Handling Slashes doesn't wok anymore. The filenames are stored without pathname.
So the V1.03 doesn't list the filenames.
This is fixed in V1.04. All files will be listed.
In next version spiffs will be changed to littlefs, because spiffs is deprecated.

Great project! It is something I has need searching for a while but I have one question... why is the second MCU required?

ESP32 is quite capable, has 2 "high" speed cores plus a low power coprocessor and plenty of peripherals, like a Hall effect sensor and an opamp to measure current and a ADC that is fast enough to count revolutions by software.

I am sure you have some reason to use the STM mcu as the core instead. I just would like to know.

Thank you very much!

Die MQTT Werte, die an den Broker gesendet werden, kommen als reine String Werte an.
Wäre es möglich, eine Option hinzuzufügen, die die Daten als JSON Paket schickt?

LG

Hello,
when using the /stmupdate webpage, I can upload the file from my Computer.
File "STM32_C2_firmware.bin" is uploaded:

file has arguments : 1
file has argument stm
filename : /stm/STM32_C2_firmware.bin
upload finished

When trying to delete the file, the webpage is accessing

"remove(): /STM32_C2_firmware.bin"

and fails. The list Please select one file: stays empty, and no update for the STM32 can be selected.

Kind regards
Alfred

I updated my vdmot C1 to the last Developer Version 1.1.1.

My problems are:
I see more valves then i have connected. On Port 1 and 3 are valves connected:

But the status side showing more valves then i have connected:

If I rescan, the count of connected valves is different, but always to much. I had this behavior with version 1.0.8 also, but after a hard reboot it works. With version 1.1.1 not.

Syslog:
192.168.178.193 Apr 08 14:28:03 1 kern debug - VdMot SysLog - - - gvlvd 1
192.168.178.193 Apr 08 14:28:03 1 kern debug - VdMot SysLog - - - STMApp:App retries 1:5
192.168.178.193 Apr 08 14:28:04 1 kern debug - VdMot SysLog - - - STMApp:App retries 2:5
192.168.178.193 Apr 08 14:28:04 1 kern debug - VdMot SysLog - - - STMApp:App retries 3:5
192.168.178.193 Apr 08 14:28:04 1 kern debug - VdMot SysLog - - - STMApp:App retries 4:5
192.168.178.193 Apr 08 14:28:04 1 kern debug - VdMot SysLog - - - STMApp:App retries 5:5
192.168.178.193 Apr 08 14:28:04 1 kern debug - VdMot SysLog - - - STMApp:App retries 6:5
192.168.178.193 Apr 08 14:28:04 1 kern debug - VdMot SysLog - - - STMApp:App retries 7:5
192.168.178.193 Apr 08 14:28:04 1 kern debug - VdMot SysLog - - - STMApp:App retries 8:5
192.168.178.193 Apr 08 14:28:04 1 kern debug - VdMot SysLog - - - STMApp:App retries 9:5
192.168.178.193 Apr 08 14:28:04 1 kern debug - VdMot SysLog - - - STMApp:App retries 10:5
192.168.178.193 Apr 08 14:28:05 1 kern debug - VdMot SysLog - - - STMApp:App retries 11:5
192.168.178.193 Apr 08 14:28:05 1 kern debug - VdMot SysLog - - - STMApp:App retries 12:5
192.168.178.193 Apr 08 14:28:05 1 kern debug - VdMot SysLog - - - STMApp:App retries 13:5
192.168.178.193 Apr 08 14:28:05 1 kern debug - VdMot SysLog - - - STMApp:App retries 14:5
192.168.178.193 Apr 08 14:28:05 1 kern debug - VdMot SysLog - - - STMApp:App retries 15:5
192.168.178.193 Apr 08 14:28:05 1 kern debug - VdMot SysLog - - - STMApp:App retries 16:5
192.168.178.193 Apr 08 14:28:05 1 kern debug - VdMot SysLog - - - STMApp:App retries 17:5
192.168.178.193 Apr 08 14:28:05 1 kern debug - VdMot SysLog - - - STMApp:App retries 18:5
192.168.178.193 Apr 08 14:28:05 1 kern debug - VdMot SysLog - - - STMApp:App retries 19:5
192.168.178.193 Apr 08 14:28:06 1 kern debug - VdMot SysLog - - - STMApp:App retries 20:5
192.168.178.193 Apr 08 14:28:06 1 kern debug - VdMot SysLog - - - STMApp:App retries 21:5
192.168.178.193 Apr 08 14:28:06 1 kern debug - VdMot SysLog - - - STMApp:App retries 22:5
192.168.178.193 Apr 08 14:28:06 1 kern debug - VdMot SysLog - - - STMApp:App retries 23:5
192.168.178.193 Apr 08 14:28:06 1 kern debug - VdMot SysLog - - - STMApp:App retries 24:5
192.168.178.193 Apr 08 14:28:06 1 kern debug - VdMot SysLog - - - STMApp:App retries 25:5
192.168.178.193 Apr 08 14:28:06 1 kern debug - VdMot SysLog - - - STMApp:App retries 26:5
192.168.178.193 Apr 08 14:28:06 1 kern debug - VdMot SysLog - - - STMApp:App retries 27:5
192.168.178.193 Apr 08 14:28:06 1 kern debug - VdMot SysLog - - - STMApp:App retries 28:5
192.168.178.193 Apr 08 14:28:06 1 kern debug - VdMot SysLog - - - STMApp:App retries 29:5
192.168.178.193 Apr 08 14:28:07 1 kern debug - VdMot SysLog - - - STMApp:App retries 30:5
192.168.178.193 Apr 08 14:28:07 1 kern debug - VdMot SysLog - - - STMApp:App retries 31:5
192.168.178.193 Apr 08 14:28:07 1 kern debug - VdMot SysLog - - - STMApp:App retries 32:5
192.168.178.193 Apr 08 14:28:07 1 kern debug - VdMot SysLog - - - STMApp:App retries 33:5
192.168.178.193 Apr 08 14:28:07 1 kern debug - VdMot SysLog - - - STMApp:App retries 34:5
192.168.178.193 Apr 08 14:28:07 1 kern debug - VdMot SysLog - - - STMApp:App retries 35:5
192.168.178.193 Apr 08 14:28:07 1 kern debug - VdMot SysLog - - - STMApp:App retries 36:5
192.168.178.193 Apr 08 14:28:07 1 kern debug - VdMot SysLog - - - STMApp:App retries 37:5
192.168.178.193 Apr 08 14:28:07 1 kern debug - VdMot SysLog - - - STMApp:App retries 38:5
192.168.178.193 Apr 08 14:28:08 1 kern debug - VdMot SysLog - - - STMApp:App retries 39:5
192.168.178.193 Apr 08 14:28:08 1 kern debug - VdMot SysLog - - - STMApp:App retries 40:5
192.168.178.193 Apr 08 14:28:08 1 kern debug - VdMot SysLog - - - STMApp:App retries 41:5
192.168.178.193 Apr 08 14:28:08 1 kern debug - VdMot SysLog - - - STMApp:App retries 42:5
192.168.178.193 Apr 08 14:28:08 1 kern debug - VdMot SysLog - - - STMApp:App retries 43:5
192.168.178.193 Apr 08 14:28:08 1 kern debug - VdMot SysLog - - - STMApp:App retries 44:5
192.168.178.193 Apr 08 14:28:08 1 kern debug - VdMot SysLog - - - STMApp:App retries 45:5
192.168.178.193 Apr 08 14:28:08 1 kern debug - VdMot SysLog - - - STMApp:App retries 46:5
192.168.178.193 Apr 08 14:28:08 1 kern debug - VdMot SysLog - - - STMApp:App retries 47:5
192.168.178.193 Apr 08 14:28:08 1 kern debug - VdMot SysLog - - - STMApp:App retries 48:5
192.168.178.193 Apr 08 14:28:09 1 kern debug - VdMot SysLog - - - STMApp:App retries 49:5
192.168.178.193 Apr 08 14:28:09 1 kern debug - VdMot SysLog - - - STMApp:App retries 50:5
192.168.178.193 Apr 08 14:28:09 1 kern debug - VdMot SysLog - - - STMApp:App retries 51:5
192.168.178.193 Apr 08 14:28:09 1 kern debug - VdMot SysLog - - - STMApp:App retries 52:5
192.168.178.193 Apr 08 14:28:09 1 kern debug - VdMot SysLog - - - STMApp:App retries 53:5
192.168.178.193 Apr 08 14:28:09 1 kern debug - VdMot SysLog - - - STMApp:App retries 54:5
192.168.178.193 Apr 08 14:28:09 1 kern debug - VdMot SysLog - - - STMApp:App retries 55:5
192.168.178.193 Apr 08 14:28:09 1 kern debug - VdMot SysLog - - - STMApp:App retries 56:5
192.168.178.193 Apr 08 14:28:09 1 kern debug - VdMot SysLog - - - STMApp:App retries 57:5
192.168.178.193 Apr 08 14:28:09 1 kern debug - VdMot SysLog - - - STMApp:App retries 58:5
192.168.178.193 Apr 08 14:28:10 1 kern debug - VdMot SysLog - - - STMApp:App retries 59:5
192.168.178.193 Apr 08 14:28:10 1 kern debug - VdMot SysLog - - - STMApp:App retries 60:5
192.168.178.193 Apr 08 14:28:10 1 kern debug - VdMot SysLog - - - STMApp:App retries 61:5
192.168.178.193 Apr 08 14:28:10 1 kern debug - VdMot SysLog - - - STMApp:App retries 62:5
192.168.178.193 Apr 08 14:28:10 1 kern debug - VdMot SysLog - - - STMApp:App retries 63:5
192.168.178.193 Apr 08 14:28:10 1 kern debug - VdMot SysLog - - - STMApp:App retries 64:5
192.168.178.193 Apr 08 14:28:10 1 kern debug - VdMot SysLog - - - STMApp:App retries 65:5
192.168.178.193 Apr 08 14:28:10 1 kern debug - VdMot SysLog - - - STMApp:App retries 66:5
192.168.178.193 Apr 08 14:28:10 1 kern debug - VdMot SysLog - - - STMApp:App retries 67:5
192.168.178.193 Apr 08 14:28:10 1 kern debug - VdMot SysLog - - - STMApp:App retries 68:5
192.168.178.193 Apr 08 14:28:11 1 kern debug - VdMot SysLog - - - STMApp:App retries 69:5
192.168.178.193 Apr 08 14:28:11 1 kern debug - VdMot SysLog - - - STMApp:App retries 70:5
192.168.178.193 Apr 08 14:28:11 1 kern debug - VdMot SysLog - - - STMApp:App retries 71:5
192.168.178.193 Apr 08 14:28:11 1 kern debug - VdMot SysLog - - - STMApp:App retries 72:5
192.168.178.193 Apr 08 14:28:11 1 kern debug - VdMot SysLog - - - STMApp:App retries 73:5
192.168.178.193 Apr 08 14:28:11 1 kern debug - VdMot SysLog - - - STMApp:App retries 74:5
192.168.178.193 Apr 08 14:28:11 1 kern debug - VdMot SysLog - - - STMApp:App retries 75:5
192.168.178.193 Apr 08 14:28:11 1 kern debug - VdMot SysLog - - - STMApp:App retries 76:5
192.168.178.193 Apr 08 14:28:11 1 kern debug - VdMot SysLog - - - STMApp:App retries 77:5
192.168.178.193 Apr 08 14:28:12 1 kern debug - VdMot SysLog - - - STMApp:App retries 78:5
192.168.178.193 Apr 08 14:28:12 1 kern debug - VdMot SysLog - - - STMApp:App retries 79:5
192.168.178.193 Apr 08 14:28:12 1 kern debug - VdMot SysLog - - - STMApp:App retries 80:5
192.168.178.193 Apr 08 14:28:12 1 kern debug - VdMot SysLog - - - STMApp:App retries 81:5
192.168.178.193 Apr 08 14:28:12 1 kern debug - VdMot SysLog - - - STMApp:App retries 82:5
192.168.178.193 Apr 08 14:28:12 1 kern debug - VdMot SysLog - - - STMApp:App retries 83:5
192.168.178.193 Apr 08 14:28:12 1 kern debug - VdMot SysLog - - - STMApp:App retries 84:5
192.168.178.193 Apr 08 14:28:12 1 kern debug - VdMot SysLog - - - STMApp:App retries 85:5
192.168.178.193 Apr 08 14:28:12 1 kern debug - VdMot SysLog - - - STMApp:App retries 86:5
192.168.178.193 Apr 08 14:28:12 1 kern debug - VdMot SysLog - - - STMApp:App retries 87:5
192.168.178.193 Apr 08 14:28:13 1 kern debug - VdMot SysLog - - - STMApp:App retries 88:5
192.168.178.193 Apr 08 14:28:13 1 kern debug - VdMot SysLog - - - STMApp:App retries 89:5
192.168.178.193 Apr 08 14:28:13 1 kern debug - VdMot SysLog - - - STMApp:App retries 90:5
192.168.178.193 Apr 08 14:28:13 1 kern debug - VdMot SysLog - - - STMApp:App retries 91:5
192.168.178.193 Apr 08 14:28:13 1 kern debug - VdMot SysLog - - - STMApp:App retries 92:5
192.168.178.193 Apr 08 14:28:13 1 kern debug - VdMot SysLog - - - STMApp:App retries 93:5
192.168.178.193 Apr 08 14:28:13 1 kern debug - VdMot SysLog - - - STMApp:App retries 94:5
192.168.178.193 Apr 08 14:28:13 1 kern debug - VdMot SysLog - - - STMApp:App retries 95:5
192.168.178.193 Apr 08 14:28:13 1 kern debug - VdMot SysLog - - - STMApp:App retries 96:5
192.168.178.193 Apr 08 14:28:13 1 kern debug - VdMot SysLog - - - STMApp:App retries 97:5
192.168.178.193 Apr 08 14:28:14 1 kern debug - VdMot SysLog - - - STMApp:App retries 98:5
192.168.178.193 Apr 08 14:28:14 1 kern debug - VdMot SysLog - - - STMApp:App retries 99:5
192.168.178.193 Apr 08 14:28:14 1 kern debug - VdMot SysLog - - - STMApp:App retries 100:5
192.168.178.193 Apr 08 14:28:14 1 kern debug - VdMot SysLog - - - STMApp:App retries 101:5
192.168.178.193 Apr 08 14:28:14 1 kern debug - VdMot SysLog - - - STMApp:Max app retries reached, set app to timeout
192.168.178.193 Apr 08 14:28:14 1 kern debug - VdMot SysLog - - - gvlvd 2
192.168.178.193 Apr 08 14:28:15 1 kern debug - VdMot SysLog - - - STMApp:got valve data #2 pos:30 mean:20 state:8 t1:-500 t2:-500
192.168.178.193 Apr 08 14:28:15 1 kern debug - VdMot SysLog - - - get one wire count
192.168.178.193 Apr 08 14:28:15 1 kern debug - VdMot SysLog - - - STMApp:one wire count 0
192.168.178.193 Apr 08 14:28:15 1 kern debug - VdMot SysLog - - - STMApp:one wire count 0
192.168.178.193 Apr 08 14:28:15 1 kern debug - VdMot SysLog - - - STMApp:one wire settings data 12 : d8-3f-6f-ea-db-b1-e9-58,d8-3f-6f-ea-db-b1-e9-58,d8-3f-6f-ea-db-b1-e9-58,d8-3f-6f-ea-db-b1-e9-58,d8-3f-6f-ea-db-b1-e9-58,d8-3f-6f-ea-db-b1-e9-58,d8-3f-6f-ea-db-b1-e9-58,d8-3f-6f-ea-db-b1-e9-58,d8-3f-6f-ea-db-b1-e9-58,d8-3f-6f-ea-db-b1-e9-58,d8-3f-6f-ea-db-b1-e9-58,d8-3f-6f-ea-db-b1-e9-58,d8-3f-6f-ea-db-b1-e9-58,d8-3f-6f-ea-db-b1-e9-58,d8-3f-6f-ea-db-b1-e9-58,d8-3f-6f-ea-db-b1-e9-58,d8-3f-6f-ea-db-b1-e9-58,d8-3f-6f-ea-db-b1-e9-58,d8-3f-6f-ea-db-b1-e9-58,d8-3f-6f-ea-db-b1-e9-58,d8-3f-6f-ea-db-b1-e9-58,d8-3f-6f-ea-db-b1-e9-58,d8-3f-6f-ea-db-b1-e9-58,d8-3f-6f-ea-db-b1-e9-58
192.168.178.193 Apr 08 14:28:15 1 kern debug - VdMot SysLog - - - STMApp:valve status 8,8,8,8,8,8,8,8,8,8,8,8,
192.168.178.193 Apr 08 14:28:15 1 kern debug - VdMot SysLog - - - gvlvd 3
192.168.178.193 Apr 08 14:28:15 1 kern debug - VdMot SysLog - - - STMApp:got valve data #3 pos:30 mean:20 state:8 t1:-500 t2:-500
192.168.178.193 Apr 08 14:28:16 1 kern debug - VdMot SysLog - - - gvlvd 4
192.168.178.193 Apr 08 14:28:16 1 kern debug - VdMot SysLog - - - STMApp:got valve data #4 pos:30 mean:20 state:8 t1:-500 t2:-500
192.168.178.193 Apr 08 14:28:16 1 kern debug - VdMot SysLog - - - gvlvd 5
192.168.178.193 Apr 08 14:28:16 1 kern debug - VdMot SysLog - - - STMApp:got valve data #5 pos:30 mean:20 state:8 t1:-500 t2:-500
192.168.178.193 Apr 08 14:28:17 1 kern debug - VdMot SysLog - - - gvlvd 6
192.168.178.193 Apr 08 14:28:17 1 kern debug - VdMot SysLog - - - STMApp:got valve data #6 pos:30 mean:20 state:8 t1:-500 t2:-500
192.168.178.193 Apr 08 14:28:17 1 kern debug - VdMot SysLog - - - gvlvd 7
192.168.178.193 Apr 08 14:28:17 1 kern debug - VdMot SysLog - - - STMApp:got valve data #7 pos:30 mean:20 state:8 t1:-500 t2:-500
192.168.178.193 Apr 08 14:28:17 1 kern debug - VdMot SysLog - - - gvlvd 8
192.168.178.193 Apr 08 14:28:18 1 kern debug - VdMot SysLog - - - STMApp:got valve data #8 pos:30 mean:20 state:8 t1:-500 t2:-500
192.168.178.193 Apr 08 14:28:18 1 kern debug - VdMot SysLog - - - gvlvd 9
192.168.178.193 Apr 08 14:28:18 1 kern debug - VdMot SysLog - - - STMApp:got valve data #9 pos:30 mean:20 state:8 t1:-500 t2:-500
192.168.178.193 Apr 08 14:28:18 1 kern debug - VdMot SysLog - - - gvlvd 10
192.168.178.193 Apr 08 14:28:18 1 kern debug - VdMot SysLog - - - STMApp:got valve data #10 pos:30 mean:20 state:8 t1:-500 t2:-500
192.168.178.193 Apr 08 14:28:19 1 kern debug - VdMot SysLog - - - gvlvd 11
192.168.178.193 Apr 08 14:28:19 1 kern debug - VdMot SysLog - - - STMApp:got valve data #11 pos:30 mean:20 state:8 t1:-500 t2:-500
192.168.178.193 Apr 08 14:28:19 1 kern debug - VdMot SysLog - - - gvlvd 0
192.168.178.193 Apr 08 14:28:19 1 kern debug - VdMot SysLog - - - STMApp:got valve data #0 pos:30 mean:20 state:8 t1:-500 t2:-500
192.168.178.193 Apr 08 14:28:19 1 kern debug - VdMot SysLog - - - gvlvd 1
192.168.178.193 Apr 08 14:28:20 1 kern debug - VdMot SysLog - - - STMApp:got valve data #1 pos:30 mean:20 state:8 t1:-500 t2:-500
192.168.178.193 Apr 08 14:28:20 1 kern debug - VdMot SysLog - - - gvlvd 2
192.168.178.193 Apr 08 14:28:20 1 kern debug - VdMot SysLog - - - STMApp:got valve data #2 pos:30 mean:20 state:8 t1:-500 t2:-500
192.168.178.193 Apr 08 14:28:20 1 kern debug - VdMot SysLog - - - gvlvd 3
192.168.178.193 Apr 08 14:28:20 1 kern debug - VdMot SysLog - - - STMApp:got valve data #3 pos:30 mean:20 state:8 t1:-500 t2:-500
192.168.178.193 Apr 08 14:28:21 1 kern debug - VdMot SysLog - - - gvlvd 4
192.168.178.193 Apr 08 14:28:21 1 kern debug - VdMot SysLog - - - STMApp:got valve data #4 pos:30 mean:20 state:8 t1:-500 t2:-500
192.168.178.193 Apr 08 14:28:21 1 kern debug - VdMot SysLog - - - gvlvd 5
192.168.178.193 Apr 08 14:28:21 1 kern debug - VdMot SysLog - - - STMApp:got valve data #5 pos:30 mean:20 state:8 t1:-500 t2:-500
192.168.178.193 Apr 08 14:28:21 1 kern debug - VdMot SysLog - - - gvlvd 6
192.168.178.193 Apr 08 14:28:22 1 kern debug - VdMot SysLog - - - STMApp:got valve data #6 pos:30 mean:20 state:8 t1:-500 t2:-500
192.168.178.193 Apr 08 14:28:22 1 kern debug - VdMot SysLog - - - gvlvd 7
192.168.178.193 Apr 08 14:28:22 1 kern debug - VdMot SysLog - - - STMApp:got valve data #7 pos:30 mean:20 state:8 t1:-500 t2:-500
192.168.178.193 Apr 08 14:28:22 1 kern debug - VdMot SysLog - - - gvlvd 8
192.168.178.193 Apr 08 14:28:22 1 kern debug - VdMot SysLog - - - STMApp:got valve data #8 pos:30 mean:20 state:8 t1:-500 t2:-500
192.168.178.193 Apr 08 14:28:23 1 kern debug - VdMot SysLog - - - gvlvd 9
192.168.178.193 Apr 08 14:28:23 1 kern debug - VdMot SysLog - - - STMApp:got valve data #9 pos:30 mean:20 state:8 t1:-500 t2:-500
192.168.178.193 Apr 08 14:28:23 1 kern debug - VdMot SysLog - - - gvlvd 10
192.168.178.193 Apr 08 14:28:23 1 kern debug - VdMot SysLog - - - STMApp:got valve data #10 pos:30 mean:20 state:8 t1:-500 t2:-500
192.168.178.193 Apr 08 14:28:23 1 kern debug - VdMot SysLog - - - get one wire count
192.168.178.193 Apr 08 14:28:23 1 kern debug - VdMot SysLog - - - STMApp:one wire count 0
192.168.178.193 Apr 08 14:28:23 1 kern debug - VdMot SysLog - - - gvlvd 11
192.168.178.193 Apr 08 14:28:24 1 kern debug - VdMot SysLog - - - STMApp:got valve data #11 pos:30 mean:20 state:8 t1:-500 t2:-500
192.168.178.193 Apr 08 14:28:24 1 kern debug - VdMot SysLog - - - gvlvd 0
192.168.178.193 Apr 08 14:28:24 1 kern debug - VdMot SysLog - - - STMApp:got valve data #0 pos:30 mean:20 state:8 t1:-500 t2:-500
192.168.178.193 Apr 08 14:28:24 1 kern debug - VdMot SysLog - - - gvlvd 1
192.168.178.193 Apr 08 14:28:24 1 kern debug - VdMot SysLog - - - STMApp:got valve data #1 pos:30 mean:20 state:8 t1:-500 t2:-500
192.168.178.193 Apr 08 14:28:25 1 kern debug - VdMot SysLog - - - gvlvd 2
192.168.178.193 Apr 08 14:28:25 1 kern debug - VdMot SysLog - - - STMApp:got valve data #2 pos:30 mean:20 state:8 t1:-500 t2:-500
192.168.178.193 Apr 08 14:28:25 1 kern debug - VdMot SysLog - - - gvlvd 3
192.168.178.193 Apr 08 14:28:25 1 kern debug - VdMot SysLog - - - STMApp:got valve data #3 pos:30 mean:20 state:8 t1:-500 t2:-500
192.168.178.193 Apr 08 14:28:26 1 kern debug - VdMot SysLog - - - gvlvd 4
192.168.178.193 Apr 08 14:28:26 1 kern debug - VdMot SysLog - - - STMApp:got valve data #4 pos:30 mean:20 state:8 t1:-500 t2:-500
192.168.178.193 Apr 08 14:28:26 1 kern debug - VdMot SysLog - - - gvlvd 5
192.168.178.193 Apr 08 14:28:26 1 kern debug - VdMot SysLog - - - STMApp:got valve data #5 pos:30 mean:20 state:8 t1:-500 t2:-500
192.168.178.193 Apr 08 14:28:26 1 kern debug - VdMot SysLog - - - gvlvd 6
192.168.178.193 Apr 08 14:28:26 1 kern debug - VdMot SysLog - - - STMApp:got valve data #6 pos:30 mean:20 state:8 t1:-500 t2:-500
192.168.178.193 Apr 08 14:28:27 1 kern debug - VdMot SysLog - - - gvlvd 7
192.168.178.193 Apr 08 14:28:27 1 kern debug - VdMot SysLog - - - STMApp:got valve data #7 pos:30 mean:20 state:8 t1:-500 t2:-500
192.168.178.193 Apr 08 14:28:27 1 kern debug - VdMot SysLog - - - gvlvd 8
192.168.178.193 Apr 08 14:28:27 1 kern debug - VdMot SysLog - - - STMApp:got valve data #8 pos:30 mean:20 state:8 t1:-500 t2:-500
192.168.178.193 Apr 08 14:28:28 1 kern debug - VdMot SysLog - - - gvlvd 9
192.168.178.193 Apr 08 14:28:28 1 kern debug - VdMot SysLog - - - STMApp:got valve data #9 pos:30 mean:20 state:8 t1:-500 t2:-500
192.168.178.193 Apr 08 14:28:28 1 kern debug - VdMot SysLog - - - gvlvd 10
192.168.178.193 Apr 08 14:28:28 1 kern debug - VdMot SysLog - - - STMApp:got valve data #10 pos:30 mean:20 state:8 t1:-500 t2:-500
192.168.178.193 Apr 08 14:28:28 1 kern debug - VdMot SysLog - - - gvlvd 11
192.168.178.193 Apr 08 14:28:28 1 kern debug - VdMot SysLog - - - STMApp:got valve data #11 pos:30 mean:20 state:8 t1:-500 t2:-500
192.168.178.193 Apr 08 14:28:29 1 kern debug - VdMot SysLog - - - gvlvd 0
192.168.178.193 Apr 08 14:28:29 1 kern debug - VdMot SysLog - - - STMApp:got valve data #0 pos:30 mean:20 state:8 t1:-500 t2:-500
192.168.178.193 Apr 08 14:28:29 1 kern debug - VdMot SysLog - - - gvlvd 1
192.168.178.193 Apr 08 14:28:29 1 kern debug - VdMot SysLog - - - STMApp:got valve data #1 pos:30 mean:20 state:8 t1:-500 t2:-500
192.168.178.193 Apr 08 14:28:30 1 kern debug - VdMot SysLog - - - gvlvd 2
192.168.178.193 Apr 08 14:28:30 1 kern debug - VdMot SysLog - - - STMApp:got valve data #2 pos:30 mean:20 state:8 t1:-500 t2:-500
192.168.178.193 Apr 08 14:28:30 1 kern debug - VdMot SysLog - - - gvlvd 3
192.168.178.193 Apr 08 14:28:30 1 kern debug - VdMot SysLog - - - STMApp:got valve data #3 pos:30 mean:20 state:8 t1:-500 t2:-500
192.168.178.193 Apr 08 14:28:30 1 kern debug - VdMot SysLog - - - gvlvd 4
192.168.178.193 Apr 08 14:28:30 1 kern debug - VdMot SysLog - - - STMApp:got valve data #4 pos:30 mean:20 state:8 t1:-500 t2:-500
192.168.178.193 Apr 08 14:28:31 1 kern debug - VdMot SysLog - - - gvlvd 5
192.168.178.193 Apr 08 14:28:31 1 kern debug - VdMot SysLog - - - STMApp:got valve data #5 pos:30 mean:20 state:8 t1:-500 t2:-500
192.168.178.193 Apr 08 14:28:31 1 kern debug - VdMot SysLog - - - gvlvd 6
192.168.178.193 Apr 08 14:28:31 1 kern debug - VdMot SysLog - - - STMApp:got valve data #6 pos:30 mean:20 state:8 t1:-500 t2:-500
192.168.178.193 Apr 08 14:28:31 1 kern debug - VdMot SysLog - - - get one wire count
192.168.178.193 Apr 08 14:28:31 1 kern debug - VdMot SysLog - - - STMApp:one wire count 0

Wenn man nur ein Stellantrieb auf 1 steckt wird dieser unter Stellantrieb 2 im Browser erkannt.

Hardwareport 1 ist Software Port 2.

V1 - No 2
V2 - No 1
V3 - No 4
V4 - No 3
V5 - No 6
V6 - No 5
V7 - No 8
V8 - No 7
V9 - No 10
V10 - No 9
V11 - No 12
V12 - No 11

Die Ports Zuordnung sind im allgemeinen etwas durcheinander.

Version 1.0.8 Beta und 1.2.2 DEV

Tritt bei beiden auf.

Wäre es möglich, die Werte vom Controller als "Retain" zu senden oder zumindest die Option als Schalter zur Verfügung zu stellen?

Hello

I have the following problem.

In my case, the kitchen is quite large, so the installer has installed 4 loops of floor heating.
Two are short, as these are to heat only a narrow edge to the outside wall.
The other two loops are long and heat the rest of the kitchen.
Each loop has its own valve.

As I understand it, only the control of one heating circuit per room is possible, right?

Would it be possible to group several circuits of a room together?

I would imagine this to be the case:
The inlet temperature must be measured with a single sensor.
Now, in order to theoretically determine the individual lengths of the combined heating circuits, a reference measurement must be made.

For this purpose, the temperature and the time until a certain temperature is reached is measured at the return of each circuit. The longest heating circuit requires the most time, the shortest accordingly less.
Based on this determined time, the longest heating circuit is now determined to the master and its return temperature is used as the setpoint for the other circuits. At the master, for example, the valve is 100% open, the other circuits correspondingly less.
If now the master must be opened more than 100%, a message is needed because of too low inlet temperature.
If now the valve with the smallest opening would have to be closed by the control, a message with too high inlet temperature is needed.

What do you say to this? Would something like this be possible?

greetings
William

If we have questions we can help us together. And we can maybe support the Project for more Members.

It will helps all.

Hi,
I am currently working on a housing to be 3D-printed and it would be helpful to have a 3D file of the assembled PCB. Is it possible to provide a stl file or some other format, I can import into Freecad?

Hi,
I am running Linux and want to flash the ESP32 with the esptool. To what adresses do I need to flash the precompiled binaries bootloader_dio_40m.bin and boot_app0.bin?

My Board D-H0044-01-05 shipped 20.09.2023.
What is the different to the old Board Design?

For flash the ESP32 Board is a wrong speed in the online Manual.
That was the reason why i cant initial flash the Board.
Correct speed setting: 921600
I use a CH340 to flash.

I'm planning to design an updated version of the hardware. Next step of hardware will be called C-sample.
Therefore i want to collect known issues and possible change requests.

currently known issues

• B4: footprint for dc-dc converter: crossed secondary side pinout for gnd and vout
• V3: false assembly of NPN bipolar instead of PNP type
• X15, 21: hole diameter to small
• X1...X12: connection to MEBP_4-4S wrong: interchange pin 1 with pin 2
• no holes for case screws

change requests

• current consumption of L293 is 50 mA each, should be lowered, maybe U1, U3, U8 should be shut down during idle
• voltage devider at net "Sense" to match voltage levels better from opamp to STM32
• bypass capacitor for ESP8266
• replace relay K1 by analog switch
• support STM32F401 blackpill boards instead of STM32F103 bluepill
• maybe switch from ESP8266 to ESP32 or WT32-ETH01
• ....

Please feel free to comment your suggestions so maybe i can consider implementing them.

Moin zusammen,

I recently upgraded from 1.0.7_Beta via 1.2.2_Dev to 1.3.0_Dev.
Not sure when on the way it happened or if I'm the only one affected, but changing tTarget via MQTT after the valve calibration run that happens after booting the device has finished (maybe even earlier) seems not do be noticed by the device.

I can clearly see the changed tTarget (coming from Home Assistant) on my broker but the controller just ignores it. If I'm rebooting if from the webinterface the new tTarget is picked up correctly.

From 18:31:00 to 18:34:00 tTarget for "Bad" should have been 19.0 and not 18.5.

Kindly let me know if you need further informations.

PS: I also tried different Interval (ms) and Publish Interval (s) values without any success.
Eike

After going to winter time the daylight saving time is still active

ESP32 Software Ver. 1.05 no longer accepts changes. I can no longer add valves or change the station name. The old settings are always there again after save config.
Already deleted the ESP and flashed it again, but still no change. Remedy has version 1.02 because everything is normal.
Got the C2 board.

Steffen

Hi Lenti,

I just set up my system and it will produce most probably some more bug reports than this, because it's huge and comes with different corner cases. But that's good - it will lead to a more reliable system. And if I have some spare time I can contribute to the development as well. That all said, lets get to the first bug report:

I've configured my system such that I can check the status of my two circulation pumps. One pump drives three VdMots and the other two. When I detect that one of the pumps is disabled (during the night) I disable the regulation by the corresponding VdMot. This is to prevent a) noise and b) unnecessary wear of the valves.

When I got it up and running I discovered that only the main valve gets parked when the controller is disabled. All the linked valves stay in their original position. I'm showing here only one controller, but the other behaves the same:

I would assume that this is not the desired behavior. Desired/expected behavior would be in my understanding, that all valves move to the parked position.

Regards!
EW

Ein Externer Fensterkontakt per Mqtt der den controller direkt anspricht um das Ventil zuzufahren wäre toll.

Derzeit mache ich es über einen Fensterkontakt der dann das stellsignal auf 0 grad setzt.
Geht, aber nicht schön aufgrund der eingestellten Verzögerung.

Fenster auf: Zwangstellung Ventil 0%, sowie blocken neuer Tempwerte (auch über mqtt)
Fenster zu: Optionen: alten Wert wieder annehnen oder aus bleiben und manuell wieder einschalten.
Wenn man die 2 Optionen wählen könnten wäre das top.

Hello
Between Christmas and New Years I soldered my board together and installed the latest software.
Mqtt is running and I get all values ​​in FHEM but can't send any. When I send values, no matter what, I see them being sent, but the values ​​do not arrive in the VdMot. This applies to sending from FHEM as well as from the MQTT Explorer.
These are similar errors as xal88 had in june 22.
What are the temp1 and temp2 fields in the Status tab for?
Are these placeholders for should and actual value?
How can I set this?
Is there anything to consider? Is there an explanation of the software on the internet?
I am thankful for every help.

Hello togetherness

Is there a description regarding the function of each input field please?

Hallo Miteinander

Gibt es eine Beschreibung bezüglich der Funktion der einzelnen Eingabefelder bitte?

Thank you
willi

Hello,
have 1 valve and 12 DS18B20 running now.
Data is forwarded to MQTT, and json can be queried by http get.

How do I set the target valve position from remote?

• json command
  how to execute "/cmd" with the stm stgtp x y ?
• MQTT changing the value setting /VdMot/valves/F01/target to 60 on the mosquitto server:
  This crashes the MQTT client, temperatures are continuing updating, valve does not.

[E][WiFiClient.cpp:395] write(): fail on fd 54, errno: 104, "Connection reset by peer"
Reconnecting MQTT...
[E][WiFiClient.cpp:485] flush(): fail on fd 55, errno: 104, "Connection reset by peer"
Reconnecting MQTT...
[E][WiFiClient.cpp:395] write(): fail on fd 56, errno: 104, "Connection reset by peer"
Reconnecting MQTT...
[E][WiFiClient.cpp:485] flush(): fail on fd 57, errno: 104, "Connection reset by peer"
Reconnecting MQTT...
[E][WiFiClient.cpp:395] write(): fail on fd 58, errno: 104, "Connection reset by peer"
Reconnecting MQTT...
[E][WiFiClient.cpp:395] write(): fail on fd 59, errno: 104, "Connection reset by peer"
Reconnecting MQTT...
[E][WiFiClient.cpp:395] write(): fail on fd 60, errno: 104, "Connection reset by peer"
valve position has changed : 0 = 50
Reconnecting MQTT...
[E][WiFiClient.cpp:395] write(): fail on fd 61, errno: 104, "Connection reset by peer"
Reconnecting MQTT... 

kind regards
Alfred

Bei Problemen beim Update sollte ein Syslog zur Fehler Identifizierung erfolgen