Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Jun 18 20:04
    rmeekers closed #92
  • Jun 18 20:04
    rmeekers commented #92
  • Jun 17 21:03
    MichielVanwelsenaere commented #92
  • Jun 17 19:47
    rmeekers opened #92
  • Jun 11 13:41

    MichielVanwelsenaere on RS485-pinout-docs

    (compare)

  • Jun 11 13:41

    MichielVanwelsenaere on master

    corrected RS485 wiring diagram … (compare)

  • Jun 11 13:41
    MichielVanwelsenaere closed #91
  • Jun 11 13:41
    MichielVanwelsenaere closed #90
  • Jun 11 13:40
    MichielVanwelsenaere labeled #91
  • Jun 11 13:40
    MichielVanwelsenaere assigned #91
  • Jun 11 13:40
    MichielVanwelsenaere opened #91
  • Jun 11 13:39

    MichielVanwelsenaere on RS485-pinout-docs

    correcting RS485 wiring diagram… (compare)

  • Jun 11 13:35
    MichielVanwelsenaere labeled #90
  • Jun 11 13:35
    MichielVanwelsenaere assigned #90
  • Jun 11 13:34

    MichielVanwelsenaere on oscat-update

    staging work (compare)

  • Jun 11 13:34

    MichielVanwelsenaere on RS485-pinout-docs

    (compare)

  • Jun 11 13:33
    MichielVanwelsenaere commented #90
  • Jun 09 20:29
    sf-prime opened #90
  • Jun 03 06:53

    MichielVanwelsenaere on oscat-update

    (compare)

  • Jun 01 14:02
    MichielVanwelsenaere commented #76
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?
Michiel Vanwelsenaere
@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.
Michiel Vanwelsenaere
@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!
Michiel Vanwelsenaere
@MichielVanwelsenaere
good to hear that, good luck!
Michiel Vanwelsenaere
@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.
Michiel Vanwelsenaere
@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
Michiel Vanwelsenaere
@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

Michiel Vanwelsenaere
@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?
Michiel Vanwelsenaere
@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.
Michiel Vanwelsenaere
@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
Michiel Vanwelsenaere
@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.
Michiel Vanwelsenaere
@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?
Michiel Vanwelsenaere
@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
fjvt
@fjvt
Goedevond :)
Heire
@Heire
Hello ;) same here. finally back some time to work on the smart part of the house when I have some time. Next step is the MQTT messages but I see smaertens has also done the same direction as I'm doing. any chance of sharing information?
Rik Verstijnen
@RikVerstijnen
Hi all, I got the project running using e!Cockpit and I must say it looks very promising! Eventually, I would like to run the basic program on the PLC and use HomeAssistant for some visualisation and more advanced controls. With regards to dimming, I have purchased a 750-652 module to control DMX dimmers. I think this is a cheaper and more scalable option than analog dimming. I was thinking of modifying FB_OUTPUT_DIMMER_MQTT to control a DMX channel instead of an analog output, but as I have no experience at all with programming PLC's, this might become a challenge. Anyone already implemented something like this by chance?
Michiel Vanwelsenaere
@MichielVanwelsenaere
Hi Rik, this might give you a headstart: https://www.youtube.com/watch?v=HaevbBvAcl0&feature=emb_title
Rik Verstijnen
@RikVerstijnen
Hi Michiel, thanks for you reply. Already found that tutorial and got it successfully running, but the next challenge will be to implement it in your code. But I will give it a try.
annD-annD
@annD-annD
Hi Rik, for controlling DMX dimmers I use Art-Net. This mean in my PLC (in my case a PFC200) I need no serial module and just send UDP-packets over Ethernet. With a selfmade Art-Net Node I receive Ethernet and send out the serial commands. In the meantime there are also Art-Net Nodes available with wireless lan and more universes. You can find codesys samples here: http://www.oscat.de/community/index.php/topic,880.0.html
Hi Michiel, is your project v1.2.0 compatible with Codesys 3.5.16.10 ? I am asking because of a problem with automatic prefixes/suffixes from function block names.
Michiel Vanwelsenaere
@MichielVanwelsenaere
Hi AnnD, hard to say, I don't try every version! Yet things should be compatible as codesys should be backwards compatible between versions. Be aware that bugs are not uncommon when trying newer versions (speaking out of experience)
To bad codesys doesn't have a page with known bugs (I already asked)
annD-annD
@annD-annD
After consulting stefandreyer with my problem there is a bug in codesys 3.5.16.0 and 3.5.16.10 which will be fixed in the next version. I just wanted to know if I am the only one with this problems regarding using funtion block names.
Michiel Vanwelsenaere
@MichielVanwelsenaere
So a bug on codesys side! Thanks for sharing over here, much appreciated!!
Rik Verstijnen
@RikVerstijnen
Hi all, I managed to control DMX dimmers via a serial module and to add off-delay timers for particular lights. So very happy overall. However, recently I am receivig "KBus watchdog timer expired" errors about 30-60 sec after the PLC has started. Any ideas?
Michiel Vanwelsenaere
@MichielVanwelsenaere
Hi Rik, great that you've managed to get things to work! Are you getting the error once or persistent after startup? I think I've seen the error/warning as well but only once after a device boot and never paid any attention to it to be honest..
Rik Verstijnen
@RikVerstijnen
Apparently my (second hand) 750-652 module was corrupted and causing KBus issues. After I removed the module, everything works fine. I would like to revert to the Artnet option. Could anyone share the code of an actual working solution? MichielVanwelsenaere/HomeAutomation.CoDeSys3#60 contains two different implementations, of which none I can get working.