Fatek PLC migration to OpenHab v3

Add-ons Bindings
1

Fatek PLC Migration Information

2 Likes
2

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

useful links:

3 Likes
3

init commit GitHub - slawekjaranowski/openhab-addons at fatekplc

4

Nie pomogę, ale trzymam kciuki :slight_smile:
Obecnie jadę dalej na OH2

5

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.

6

Witam.
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

7

Hi, guys please use english in public messages.

1 Like
8

[offtopic] This forum will be taken by :poland: in 3… 2… :wink:

9

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.
4 Likes
10

Hi, it’s great news!:), all I can offer is help with tests.

11

Hello Slawek,
Any progress for fatek binding for Openhab 3.0?

12

Any chance to have fatek binding for openhab3? I am stuck with old version 2

13

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.

3 Likes
15

Keeping my fingers crossed. Let me know if you need someone to betatest.

16

Hi, all The New Year so new resolution. :wink:

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.

3 Likes
17

I watching this thread long time.
But only in testing I can help :frowning:

edit:
Any news ? :slight_smile:

18

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
or even
Things - channels

1 Like
19

Hello Slawek,
Any progress to rewrite binding to Openhab 3?

1 Like
20

Any progress

21

I always was fan of opensource but I am starting to understand people having bad opinion about it - when you are waiting 2 years for new version, beeing stack for old version because of one component.