by

Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • May 25 09:09

    MichielVanwelsenaere on binarysensor-hysteresis

    (compare)

  • May 25 09:08

    MichielVanwelsenaere on master

    Adding a configurable turn off … (compare)

  • May 25 09:08
    MichielVanwelsenaere closed #71
  • May 25 09:08
    MichielVanwelsenaere closed #70
  • May 25 09:06
    MichielVanwelsenaere labeled #71
  • May 25 09:06
    MichielVanwelsenaere assigned #71
  • May 25 09:06
    MichielVanwelsenaere opened #71
  • May 24 06:46
    MichielVanwelsenaere commented #70
  • May 23 16:57
    primsam commented #70
  • May 22 09:27
    ArjanM83 commented #70
  • May 22 09:19

    MichielVanwelsenaere on binarysensor-hysteresis

    minor typo correction (compare)

  • May 22 09:18
    MichielVanwelsenaere commented #70
  • May 22 08:44
    MichielVanwelsenaere commented #70
  • May 22 08:38

    MichielVanwelsenaere on binarysensor-hysteresis

    adding turn off delay option on… (compare)

  • May 22 08:16

    MichielVanwelsenaere on binarysensor-hysteresis

    (compare)

  • May 19 07:16
    DomiGijzen commented #70
  • May 18 08:40
    ArjanM83 commented #70
  • May 18 07:42
    MichielVanwelsenaere commented #70
  • May 17 16:20
    primsam commented #67
  • May 17 12:32
    ArjanM83 commented #70
yniezink
@yniezink
i'll do a factory reset
MichielVanwelsenaere
@MichielVanwelsenaere
just created a new release! which brings me automatically to the next milestone (v1.2) being RS485 support
with some professional PLC programmers being present here, is there any way to develop modbus rtu communication logic in an IDE independent environment? from what I'm seeing right now, there are quite some differences in how to add a modbus device in Codesys 3S and in é!Cockpit
é!cockpit for example requires wago libs in their examples
Codesys 3S has a gui approach, no libs involved
needles to say, but feel free to star if you haven't already, I really appreciate it :)
MichielVanwelsenaere
@MichielVanwelsenaere
@Sandolution, any idea on the modbus rtu question?
Sander
@Sandolution
@MichielVanwelsenaere as far as I know, modbus RTU is quite hardware specific. Lenze also has a special modbus slice with a custom library needed. Same as e!cockpit. So it's a difficult topic. I'm not sure what the codesys approach is and what hardware they use.
Did you get a change to look at my project? We need to discuss about the possibilities to merge the projects into one.
MichielVanwelsenaere
@MichielVanwelsenaere
thanks for confirming that! I had a first look but need to do a deep dive in your libraries.. I have some work abroad coming up later this month and the plane time will be ideal to have a deeper look :)
Dominique Gijzen
@DomiGijzen

Following the plc topic on tweakers now for a while. Got into the MQTT package yesterday and really am still trying. But thnx so far for the work done! Also nicely documented.

You asked about deadlines and such. Don’t really have a deadline. Requirement for me is ease of use of the backend. Other than that, I’m starting with the heating and monitoring of my house.

Would be glad to help. But on this discipline I’m probably just a tester.

MichielVanwelsenaere
@MichielVanwelsenaere
That's fine, testing is contributing as well! I'm hoping to be able to create some basic heating approach documentation later this month on the approach I'd like to take, when done I'll post a message here so it can be reviewed before I start actual development
Dominique Gijzen
@DomiGijzen
Question, followed the starting guides on github. Now, is see the availability topic coming at my MQTT broker (symcon) with value online. Also the plc confirms it has connection by the green user light.
While following the guides, I keept DI_001 and DO_001. Also configured the output to be toggled by input 1.
But I’m not seeing this topic or anything else than the availability coming in at the broker.
Am I missing something? Or someone any tips?
MichielVanwelsenaere
@MichielVanwelsenaere
are you triggering an event on the physical input DI_001 like a pushbutton? Feel free to send me a copy of your code so I can check it, if the availability topic is working I'm sure it's something small
Dominique Gijzen
@DomiGijzen
I think I’m. Do I need to set this up as an extra step or is it already in the example code?
MichielVanwelsenaere
@MichielVanwelsenaere
everything should be there, my question is perhaps not a 100% clear; do you have something wired to the DI_001 physical input of your PLC?
nothing will be transmitted through MQTT if nothing is happening
Dominique Gijzen
@DomiGijzen
I see. Yes there is a physical button and the DI_001 reacts and the DO_001 response on a single push. I see the lights on the PLC react. I can also see the software recognizing single, long and double presses.
Just tested Symcon if does receive a random published MQTT message and it does. What would be the best way to share code? NVM: just saw your message.
MichielVanwelsenaere
@MichielVanwelsenaere
don't know symcon but can you connect to the MQTT broker with another tool and subscribe to all topics? Or is that what you are doing with symcon? will check your code as well
Dominique Gijzen
@DomiGijzen
Symcon is indeed the broker. But you triggered me to try mosquitto as a broker and see what is coming by. The other message are send by the plc. So the problem is within in symcon. Tnx so far!
MichielVanwelsenaere
@MichielVanwelsenaere
good to hear that, good luck!
MichielVanwelsenaere
@MichielVanwelsenaere
Hi guys, I wrote a HVAC whitepaper to explain the idea, sensors and actuators that would be behind the function blocks for HVAC. Please give it a read, it's quite important to get this right from the start!
roomboot
@roomboot

Nice job, looks really promising! I would like to add some of my own considerations. Many of these are more of my own end-goals for a complete heating system.

  • Option for multiple valves per room.
    Rooms can have multiple underfloor heating circuits. The largest room in our house has 4 zones, so 4 valves that need to be opened. This could just be done by copying the output to multiple io's, but that isnt always ideal.

  • Uneven heating multiple zones in a single room to account for heat loss near (badly insulated walls or) large windows.
    We have large glass facades, for example in our kitchen, so we've put 2 of the 4 circuits along the windows. When it's cold outside with lots of wind, a lot of heat is lost through the windows. The air near the windows is noticably colder and so is the floor. Thats why i'm thinking of boosting the heating circuit near the windows to keep the temprature more equal across the room and floor. I'm not sure if this requires measuring the return flow temprature or if maybe just giving the 'outside' cirquits a general boost would be sufficient.

  • Option to use the endstops included in some valves.
    Thermo electric valves take about 3 minutes to fully open or close, depending on the model ofcourse. Mine have integrated endstops (wasn't planning on it, but the shop sent these so I might as well try to use it?). These close a cirquit once the valve is fully open, making detecting of fully 'open' possible and guessing of floating ('opening' and 'closing') and 'closed' valve states possible.

  • Main pumps and distributor pumps.
    Some cirquits use a general pump (can be located in CV, but mine is seperate) to supply multiple distributers, which in their turn also have their own seperate intergrated pumps. If all distributor pumps are off, the main pump can also be shutdown.

  • External factors like weather and direct sun
    These factors can have a large impact on comfort in any installation. To me the main ones are outside percieved temprature (including wind speed) and sun intensity (and direction). Combined with some information about the room (eg. are there sun receiving windows? What direction do they face? Are there shutters enabled for this window?) can help in calculating sun heating.

  • Intergrating wheater and heating based shutter control
    eg cooling or heating a room with the sun, depending on shutter state, amount of glass (with direction) in a room and angle of the sun. Constantly changing the shutters get's anoying really fast. So this should use a prediction of sun intenisty and required heating (planned or 7-day average maybe?) to change the shutter accordingly and stick to it for a set amount of time.

Petorrrrr
@Petorrrrr
Hey all. Quick introduction. After finally being succesful to apply the codesys 3.5 runtime to my PFC200 (I'm one of the unlucky ones who bought one without the e!cockpit runtime installed) I dived into the project. I succesfully managed to get the PFC to send out DMX over ArtNet and together with the FB_OUTPUT_DIMMER_MQTT function (which I edited a little to accomodate my requirements of the double click to alternate between the min and max value of the dimmer) I can now dim the lights :)
I'm very new to github and all, and I'd like to share my progress on the ArtNet part, but I'm not sure how to. The ArtNet makes use of the OSCAT NETWORK library so I think it should be able to run in both codesys 3.5 and e!cockpit runtime. Can someone help me out with sharing this?
Petorrrrr
@Petorrrrr
Also I think it would be really helpful if the VIRTUAL FB's also had another output which sends the OUT value, but only during one cycle. This way you can mimmic a pushbutton and not just a switch.
MichielVanwelsenaere
@MichielVanwelsenaere
Hi @Petorrrrr , great to hear that you've managed to do ArtNet communication using the OSCAT NETWORK library, definitely something other people can use as well!
To share things you can export your project as an OpenPLC xml file and select the FB, tasks, etc (pieces of code) to an XML that is more easy to read than Codesys/é!cockpit binary files
I suggest you create a git issue on the repo (https://github.com/MichielVanwelsenaere/HomeAutomation.CoDeSys3/issues) and elaborate on what you've implemented with regards on Artnet and how it works. Add the OpenPLC xml file and possibly the codesys file as well as an attachment (please remove MQTT broker credentials if present) and we'll go from there
MichielVanwelsenaere
@MichielVanwelsenaere

Also I think it would be really helpful if the VIRTUAL FB's also had another output which sends the OUT value, but only during one cycle. This way you can mimmic a pushbutton and not just a switch.

So basically for the BOOL VIRTUAL FB you have a 'auto reset' functionality in mind so the OUT value is only assigned for one clock cycle? I can understand that that can be usefull, feel free to open a git issue for that as well so I don't forget to have a look at that :)

yniezink
@yniezink
+
Petorrrrr
@Petorrrrr

Also I think it would be really helpful if the VIRTUAL FB's also had another output which sends the OUT value, but only during one cycle. This way you can mimmic a pushbutton and not just a switch.

So basically for the BOOL VIRTUAL FB you have a 'auto reset' functionality in mind so the OUT value is only assigned for one clock cycle? I can understand that that can be usefull, feel free to open a git issue for that as well so I don't forget to have a look at that :)

I fixed this myself (it's included as well in the code of issue #60 ) in some rudimentary form, but can't recall exactly what changes I made to your original function block(s). Nothing too big I think

MichielVanwelsenaere
@MichielVanwelsenaere
thanks, I'll check it..
smaertens
@smaertens
Will start working on the mqtt implementation here :) I will try and use your function blocks but my first attempts will be with the native mqtt blocks from Wago. Will let you know the outcome.
smaertens
@smaertens
Michiel, what exactly happens when the MQTTlibrary has no connection with the broker. All messages get queued up in your FB_MqttPublishQueue? To cache them and send them out once the connection is recovered?
MichielVanwelsenaere
@MichielVanwelsenaere
Yes, but take into account that the buffer can only hold a 1000 messages (can be increased) and is circular. This means that if the 1000 messages limit gets reached the newer messages will overwrite the older messages
The queue is more intented to have things loosely coupled and the cache behaviour is a nice side behavior 🙂
smaertens
@smaertens
Ok I understand. I was doing some tests with a small program that is putting an output on / off / on etc. When the queue is filling up, when the connection is there again, all those messages are sent to the broker at once. Made me wondering if this is behaviour I really want. I was thinking of maybe there could be an algorithm that in case of reconnection only the latest status for every different object was sent to the broker.
MichielVanwelsenaere
@MichielVanwelsenaere
I understand as well 😉 it's something I spend quite some thought on when developping this. It could perhaps be approached differently but there's allot of complexity there. Take into account that there are 40 send processes and an unknow number of FB's that require MQTT publishes. After some thinking I decided that until the difference has been proven it is a design overkill to take this into account..
Felt like that time was better investigated in a decent network setup then to go deep into a scenario that might never give any issues
MichielVanwelsenaere
@MichielVanwelsenaere
I'm also not sure whethet it's possible to know with a 100% certainty if the connection with the broker is down BEFORE a message is published by a function block, a very small detail that makes a huge difference from a design perspective
Let me know your thoughts9
smaertens
@smaertens
In the native implementation of MQTT for Wago, they make use of a library (WagoAppCloud). That works together with a daemon that runs on the Wago PLC OS. It is that daemon, following the wago documentation that is doing the caching. So that is again, a whole different setup. Since I am using purely Wago stuff (including e-cockpit) I decided to try out those libraries first. I have changed your implementation to just have the queue and one process that just continuously empties the queue. (And in my case, sends it through to the daemon that will cache it if necessary). Since this is my first real codesys project I have not enough experience with it and will fall in some implementation-traps for sure :D Time will tell. I needed some hours to really figure out how your implementation was done. Pretty impressing and a bit overwhelming sometimes at first :). Big learning step for me. Congratulations to you.
MichielVanwelsenaere
@MichielVanwelsenaere
So the Wago library also caches messages if the connection is down? Any specific reason why you are adopting the Wago function blocks? Yes, you'll have a learning curve but that is to be considered a good thing ofcourse! If you have any questions, let me know!
smaertens
@smaertens
This is what the documentation says: The Linux Application is connected to the IEC Library using Inter-process communication (IPC) and also communicates with the Cloud. Data transmission to the Cloud is done by using the MQTT protocol and is encrypted using TransportLayerSecurity(TLS). Furthermore the Linux Application caches data coming from the PLC program to avoid data loss in case network connection to the Cloud got interrupted. Caching can be configured within WebBasedManagement (WBM) either in RAM or on a storage medium (SDCard). LinuxApplication takes care about automatic reconnect. The PLC library WagoAppCloud forwards the data to the Linux application which sends the data to the cloud. In the PLC application the application engineer has to... - define the variables which shall be send to the cloud define the commands which can be called by the cloud
smaertens
@smaertens
I have not changed your Wago function blocks. I have just changed the implementation from the 40 workers to one process in the background that just empties the queue and sends the messages. Since this was easier for me to start comprehending and debugging the whole thing. Since in my case I am just sending the messages down to the Linux Daemon ... I guess there is no need to have parallel workers sending out the messages. The reason why you have those workers is because it can take a while to buildup the communication and actually send the bytes, if you can do more than a few in parallel all the messages will be gone sooner, am I correct there?
MichielVanwelsenaere
@MichielVanwelsenaere
We're going a bit into the details of the MQTT lib which I didn't implement but the communication is maintained by the client and the tcp connection is kept allived. The 40 processes are there to send 40 messages simultinously. A process maintains the state of the message, like is it acknowledged by the broker or not.. Again, this is quite into depth on the MQTT lib but the above should be more or less acurate..
yniezink
@yniezink
Finally got some time to tinker with my PFC200. Got the project running using ecockpit. Time to expand my test setup and see how to integrate with Home Assistant