Nothong prevents you from writing new version of binding. 
If i was developer i could. Applications are not only for developers.But mainly for normal users, also opensource
@marcin_st I could do basics somewhere in April. I just need to buy myself a fatek plc for tests. I need most basic setup which will serve development (ethernet / rs232 / rs485) and allow to validate various register kinds available to programmer. Any advices? I will pay myself for hardware, but then you need to give me a plc program and assist me in getting it working.
2 Likes
Hello Ćukasz,
Many thanks. I have fatek (central unit with 3 extension units) about 70 inputs and 70 outputs - so my program will not be usable for you. But i can write simple one with few rules working only on central unit. So you could verify main registers (X - inuts, Y - outputs, T - timers).
I dont have Ethernet extension. I am connecting with openhab via USB cable delivered to configure PLC.
Maybe usefull info - in previous binging jfatek library was used.
Hi Ćukasz, Fatek FBs-20 with Fatek FBs-CM55E itâs rs485 and Ethernet expansion module or Fatek FBs-CBEH itâs Ethernet expansion board will be ok for test. When you will have PLC let me know which model you have i will write lader for testing X,Y registers and so on, i can help you with work from Fatek side.
Hello Ćukasz, did you manage to start? Do you need any help?
I did manage to get things started. I received PLC from Jiri (FBs) and test program from @Alien. I got it up and running and did some tests with jfatek as well as discovery of fatek plc/ethernet modules.
Iâll be making more progress on binding itself. I wish first to complete verification of jfatek and mapping of values to/from plc to avoid miss-implementation of openHAB side. Hopefully next weekend (6-7.05) Iâll have some stuff to deploy.
Cheers,
Ćuaksz
2 Likes
Great info. Thank you.
Hello,
I am working on binding (sorry for time skew!), and got basic infrastructure in. As I go over further steps I also fall into some questions. One of them is how you connect your PLCs and if you have more than one.
Looking at Fatek I see that connection parameters in jfatek (SĆawekâs library) have a plcId parameter which remains static for entire connection. While it is not a problem for TCP connections (I suppose!) I have doubts if its going to work with serial connections. In such case one line can be connected to multiple PLCs, each having its own station number.
Can you please share your use cases which include more than one PLC using serial connection? Also, if you could outline how you managed it so far with openhab 1.x binding or modbus, it would help me with modelling of bridge/thing relations.
Best,
Ćukasz
Hello
I have connection through USB (serial port). But i have only one PLC (one main unit with 3 extension units).
Maybe Author of original binding could answer this questions.
I was thinking about this:
there is config file for fatek binding:
fatekplc.cfg
i have this:
refresh=1000
fatek1.connectionUri=serial:///dev/ttyUSB_fatek?plcId=1
then i add items:
Switch Fatek_Y_10 {fatekplc=âfatek1:Y0010â}
so if you have two PLCs there should be no problem as they have separate serial ports, separate config lines and then separate items based on this
I believe plcId=1 is the same as station number for TCP connection, indicator of specific PLC unit. Hence it should work with serial connection similarly to TCP.
Hi Ćukasz, You can omit station ID in TCP or UDP itâs important in serial connection. In more then one PLC scenario one PLC is master and rest is slave so we will read only one PLC, unless you have more then one serial port so every PLC is independent as @marcin_st mentioned. Furthermore more then one PLC in home automation is not good idea, itâs like two OpenHab. But this is only my point of view 
Iâve already found a way to make a single TCP/UDP/serial connection with dynamic plc id/station number thanks to java reflection api. While it seemed redundant in first run I found a justification. There is a way to discover IP address of Fatek PLC through UDP broadcast. Sadly UDP answer does not contain station number thus I would have to make a whole bunch of TCP connections just to iterate through available identifiers to find a working jfatek connection string.
I am cleaning up the UDP code I made while experimenting. More changes to follow.
3 Likes
You dont need the plc , only to download " winproladder " from fatek website and run the simulation . The adress is " you local pc adress port 500" . Alow in winproladder program TCP connection " UDP" not suported in simulation. In status page can ad any register to modify in real time . Unfortunately for me i dont understand openHAB , to many languages involved in one piece of software , and documentation is written in creator view. If you need help with ladder i can made any request in. 2 min. Thanks
Iâve received a PLC from @skuhrovec.j and ladder from @Alien, so I could test serial and tcp connections as well as discovery of devices. Thanks to their support I was able to start working on this.
I am approaching thing handler implementation which most likely will be extensible - meaning one PLC thing will have configurable channels reflecting various registers of Fatek devices. Once I get first two channel kinds (contact/switch and number) Iâll be ready to release an alpha version.
If any of you wish to help further - there is a way to read register names/comments stored on PLC via winproloader. If you could look how to parse packet or what packet/command to send to get this information, then we could make also dynamic discovery of channel labels. If winproloader does it, and it does via tcp as well, anyone can do.
1 Like
Yea, anyone can do , but is hard to do. That was my first intention 4 years ago , after getting tired of raspberry pi and dsPIC microcontrollers , to may pieces to control my house , one fail in a winter and heat pump stuck 1 day at -26*C outside. I got piss off and i buy a PLC and HMI. , programmed and in 4y not a single error. I know from then, winprolad use the wshtcpip.dll windows64 service when change data to PLC (TCP on UDP canât find)and that get init by Prolad10.dll from folder instalation. I try to sniff with PRTG , Charles ,no chance to get the packet end that days.
wshtcpip dll exchange data when click start UDP connection
Do you need the packets when exchange data with prolad right ?
I will try again and i let you know if i discover something .
Personaly i want only to red/write registry of plc with alexa echo dot control âwife prefferenceâ
Thanks
Checking the PLC with different tools , all response with
HostName : 192.168.1.3
Address type : 02 (AF_INET)
Address : 192.168. 1. 3
so⊠i asume the fatek protocol is https://www.ibm.com/docs/en/i/7.2?topic=family-af-inet-address
And here is free software for capture , indeed working but not to much to understand
https://packetbuilder.net/product-overview.html
and here , thats my PLC , data have the same length i saw in debugger wshtcpip.dll and i changed to UDP.Protocol differ but the data is the same https://prnt.sc/p0eJcyM4rKRh
You can capture network level packets using wireshark. It is not an issue with this tool.
Indeed, this is hardest part for now - finding out which packets are responsible for retrieving program from PLC and how this packet is structured. There is fair amount of traffic between winproloader and PLC, it is pretty hard to find right packet. Back when I was looking at this I found several longer packets, but had no time to look closer at them. If you can - try creating a minimalistic program with one or two registers and modify names (one or two characters). Some packets should reflect that change. Later, if you trace/identify related transmission kind you can try adding name to later register in same fashion and see if later part of payload changes too.
A good chance could be also capturing packets sent to PLC when winproloader sends ladder to device. I suppose that written program and retrieved program, beyond header will remain the same.
I found somewhere in one of PDFs program structure - have to look for it when Iâm back at my desk.
Found this: https://www.esea.cz/support/fatek/FBs_Manual/Manual_1/instruction/Chapter_2.pdf - see first page, for us interesting part is label section of ladder program area.
Yes and no . I was thinking last night why to bother with packets and sniff when are already many drivers to communicate , and obviously all have same protocol.
I upload to drive what i found in my computer about fatek drivers. Are 3 drivers there , 2 in .dll format
and other one is a VB application and have the project there .
fatek drivers for weintek HMI, proface HMI and facom
The weintek and proface are installed in my house , and i search in my PC , the facom in visual basic is from a old hardware , i donât use anymore .
Tested facom driver server , is very fast response , no bug or other issues , can aces everything.
For skilled guys maybe is a real help
Thanks