Converting an OH1 Item to OH2

What do I need to do to the following item to make it compatible in OH2

Switch Hallway "Hallway" (VANTAGE){ tcp="<[10.5.1.6:3040:'MAP(90.map)'], >[ON:10.5.1.6:3040:'MAP(90.map)'],>[OFF:10.5.1.6:3040:'MAP(90.map)'] ", autoupdate="false" }

Nothing, the tcp binding is a 1.x binding, so you just have to adapt the configuration of the binding:

http://docs.openhab.org/tutorials/migration#configuration-and-folder-structure

Can you be a bit more specific? I’ve set up the new separate CFG file but the switch does not work. Do i need to use Chanels?

Can you help with a little more practical information?

Thanks,

Squid

It is just as @sihui says and what I tried to explain you here: There is no difference in OH2 regarding the use of the TCP binding. Just keep your item file as is.

Create a tcp.cfg file and put your config from openhab.cfg into it, BUT: remove the tcp: part, f.e.
tcp:refreshinterval=250 in your openhab.cfg becomes
refreshinterval=250 in your tcp.cfg.
Do that with all of your config parameters and it should work.

No, channels are only available for 2.x bindings. Your items stay the same.

1 Like

Hello All -

First off thank you to everyone who provides help to those of us who need it to get our setups going - it is greatly appreciated.

I was able to figure out my issue.

It was frustrating that everyone was telling me “you do it exactly the same way as you do it in OH1” and I was doing that! I copied my item information exactly from my OH1 installation and nothing was working…I was checking syntax and re-checking syntax.

Late this evening I enabled more detailed logging to discover an error of

"Cannot get service reference for transformation service of type MAP"

Low and behold I discovered in OH2 you must INSTALL the MAP Transformation service - this is a service that is installed by default in OH1.

So chalk this up to it being almost like OH1…this is where the assumptions/documentation issue that @rlkoshak and I were discussing earlier becomes very apparent. This is not meant to be an knock, rather an observation.

I am very appreciative of the guidance, support, and the product all of you have spent many hours investing in.

Thank you for everything you do!

This is covered in the migration tutorial which is in progress of being moved to the official docs.

The following isn’t an accusation or a “RTFM” comment. Did you know about and read the tutorial? Did you know about the admittedly lacking tutorial on the main docs page? If so please tell me which parts were confusing or lacking so I can address those. I’m currently working on it right now.

I am surprised you needed to enable more detailed logging to see that error. You should see errors like that with the logs at the default level. That is of concern. Can you tell me what you changed to see the error?

Hey Rich -

Unfortunately I was unaware of the migration tutorial that you prepared…WOW wish I would have had my eyes and hands on it before I began my journey to OH2. There is some really great stuff in there.

<NON-RANT>

I think this continues to illustrate the challenge of centralized information and documentation. I’ve been pointed to many different places to look in the past such as:

  • These Forums
  • The official Docs
  • The Google Groups pages
  • Pages on GitHub
  • Eclipse Smart Home Forum

I’ll be studying your guide as I’d like to get everything moved over and now plan on integrating the Amazon Echo Hue Emulation. Once again thank you for all that you do.

…I’ll look up the logging I turned on this evening when I get home.

The pages at https://docs.openhab.org are supposed to be that centralized location. However, as you can see, they are not yet ready to take on that role. Lots of work needs to be done and it is all work we know needs to be done. It is not getting done as fast as anyone would like.

Several of the tutorials I’ve written as threads on the forum so far, the Migration Tutorial included, are intended to be public first drafts. And the Tutorials and Examples section is the main place to go right now for a lot of these not yet incorporated into the main docs.

Hi KidSquid I also have a Vantage Qlink system. Could pick your brain about what you have got working and what is not worth doing. Can you send me a private message?

@DavidL

Happy to share what knowledge I have. What are you looking to do?

I’d like to be able to send commands to the tcp/ip enabler what app or options do I have?

@DavidL

So I utilize the TCP Binding to do all of my communications between OH and the Vantage Qlink System.

You’ll need to install the TCP Binding and if memory serves it’s still a 1.0 binding so you’ll need to create a .cfg file and place it in the SERVICES folder.

My tcp.cfg file looks like this…

# all parameters can be applied to both the TCP and UDP binding unless
# specified otherwise

# Port to listen for incoming connections
#port=25152

# Cron-like string to reconnect remote ends, e.g for unstable connection or remote ends
#reconnectcron=0 0 0 * * ?

# Interval between reconnection attempts when recovering from a communication error,
# in seconds
#retryinterval=5

# Queue data whilst recovering from a connection problem (TCP only)
#queue=true

# Maximum buffer size whilst reading incoming data
buffersize=1024

# Share connections within the Item binding configurations
itemsharedconnections=true

# Share connections between Item binding configurations
bindingsharedconnections=true

# Share connections between inbound and outbound connections
#directionssharedconnections=false

# Allow masks in ip:port addressing, e.g. 192.168.0.1:* etc
addressmask=true

# Pre-amble that will be put in front of data being sent
#preamble=

# Post-amble that will be appended to data being sent
postamble=\r

# Perform all write/read (send/receive) operations in a blocking mode, e.g. the binding
# will wait for a reply from the remote end after data has been sent
#blocking=false

# timeout, in milliseconds, to wait for a reply when initiating a blocking write/read
#  operation
#timeout=3000

# Update the status of Items using the response received from the remote end (if the
# remote end sends replies to commands)
#updatewithresponse=true

# Timeout - or 'refresh interval', in milliseconds, of the worker thread
#refreshinterval=250

# Timeout, in milliseconds, to wait when "Selecting" IO channels ready for communication
#selecttimeout=1000

# Used character set
charset=ASCII

The postamble flag was a biggie for me…the \r is what i needed to add so that OH would send a CR after sending the correct Vantage parameters.

Next you need to set your items up, in speaking with one of the engineers at Vantage he told me to always target the button, not the load. So that is what I have done.

If you look at the following item for my Kitchen lights, this is how I toggle them off. I also need to use a MAP transformation which you need to install via PaperUI as well. The kitchen.map file is saved in the TRANSFORM folder.

Switch Kitchen "Kitchen" [ "Switchable" ] {tcp=">[ON:10.X.X.X:3040:'MAP(kitchen.map)'],>[OFF:10.X.X.X:3040:'MAP(kitchen.map)']"}

Map File:

ON=VSW!1 98 2 6\r
OFF=VSW!1 98 2 6\r

The VSW!1 98 2 6 is the switch id from vantage.

According to the Vantage documentation:

The format of each command is:
VXX{S} { {}}
Where V is the command start character, XX is the 2-letter command, and S is an optional special character that overrides the default response format setup in the VCL command. The optional specify information for each command. All data sent and received over the RS-232 interface should be in ASCII format and in all capital letters.

Valid values for the optional special character S include:
S Description
! Don’t send any response for this command.
@ Send a regular response for this command.
#Send a detailed response for this command

So what I am basically doing is toggling the switch on and off. What I am not doing well at this moment is capturing the state of the button when it get’s turned on manually and making sure that OH displays the same state. I think it’s possible but need to read through the documentation a bit more to see if i can do it without a bunch of “dummy or proxy” switches that have been mentioned before.

The 10.X.X.X is the IP address of my IP enabler.

The tag of [ “Switchable” ] is for use with the HUE Emulation which allows me to ask Alexa to turn the lights on or off.

Does this make sense to you? It took me a bit to get my head around it…let me know if I can assist and if you take it further please let me know what you come up with.

Squid

Squid,

Thanks a lot, I can tell you have put a ton of time into this! I think I get most of it but it is a lot to get my head around.
Is OH a good fit for this? Also have you tried other ways to control Qlink from iPhone or Android?

David

Happy to help out…as others have and continue to help me along my journey. :slight_smile:

I think OH is a great fit for it…it will take some time and you’ll need to roll up your sleeves and get a bit dirty but the results will be worth it.

In regards to controlling Qlink via other methods…there used to be an iOS and Android app but the app is no longer available and even if you were to find the old APK it does not run well at all. There is a mobile OH app and once you get it working in OH you’ll have a mobile option that will work as well.

As I’m sure you are aware, Vantage has discontinued Qlink and replaced it with inFusion. Vantage does offer a conversion kit but that will require working with an Authorized dealer and having them replace and reprogram your controller - unless you want to look at buying one off eBay and figuring out how to program yourself.