Fatek PLC Migration Information
Because OpenHAB v3 has different architecture than v1 I will start from preparing documentation for new Fatek PLC binding.
I need help from others who are more familiar with OpenHAB v3 to do first step, so any suggestions are appreciated.
When we will have documentation, how new binding should be used and configured implementation will be easier.
I don’t want to start implementation without good understanding how it should working.
So I’m waiting for your feedback
Nie pomogę, ale trzymam kciuki
Obecnie jadę dalej na OH2
How can I help? I’m always ready for performing some tests or help in the other way than programming.
Maybe fatek binding should work similar to MODBUS binding where every specific coil, input, register, marker is treated as single Thing? Just thinking.
Niestety w programowaniu nie pomogę ale mogę wystawić na stałym IP fateka do testów. Jakieś hmi weintek też znajdę.
Jak coś to pisać / dzwonić 511 27 10 41
Hi, guys please use english in public messages.
[offtopic] This forum will be taken by in 3… 2…
Here are some tips:
- For the serial connector. The code can remain mostly the same. But use the openHAB serial transport layer instead of gnu directly. The configuration can be passed via thing configuration. See for example how this is done in the DSMR binding.
- With regarding to things design. It looks like the connection is a bridge thing, and slave are things with channels.
- The channels are dynamic. So in the thing definition use
extensible. See for example the mqtt generic
- Items in openHAB 1 implementation can be treated somewhat similar as channels in openHAB 2/3. So you can reuse the concepts of item classes, but maybe rename to use openHAB 3 namings.
- item connfiguration in openHAB 1 was done by having a concatenated string of values. You could use a similar aproach as a channel parameter. However, it’s probably better to model each configuration as a separate channel parameter. This is because this allows for better ui experience. Because if the user has to construct the string as in openHAB 1 the user needs to know the syntax. By using a parameter for each configuration then the user can easier configure. This also means you don’t need to do the string splitting in the code, but just read the channel configuration.
Hi, it’s great news!:), all I can offer is help with tests.
Any progress for fatek binding for Openhab 3.0?
Any chance to have fatek binding for openhab3? I am stuck with old version 2
Thanks all for interesting in the topic …
I still thinking about it, but last time I’m a little busy
I also use old version of OpenHab so … I try to find some spare time …
I can’t promise anything … when I start working I will let you know.
Keeping my fingers crossed. Let me know if you need someone to betatest.
Hi, all The New Year so new resolution.
I have plan to start working on it of the end of January - after winter holidays …
So it will be very useful for me if someone help to write documentation for binding.
I think that starting of documentation will be necessary because I need to learn new architecture of OpenHab.
So if someone is ready to help I can give access to my fork of OpenHab on GitHub and we can work together - let my know your GitHub account name.
I watching this thread long time.
But only in testing I can help
Any news ?
I meant to comment on this earlier. The Modbus structure is a little unusual;
device Bridge - poller Bridges - data Things - standardized channels
because it was meant to model the hugely flexible generic Modbus device. We’d learnt from v1.x binding usage what weird and wonderful ways different device designers could use to arrange a few simple registers e.g. reading from one address and writing via a different address.
Where you are dealing with a single manufacturer’s consistent protocol, you probably could/should adopt a simpler approach
Bridge - Things - channels
Things - channels
Any progress to rewrite binding to Openhab 3?