Event Listener

[KidSquid (The Squid)]

I have finally figured out a way for OpenHab to talk to my lighting system, now I need to have OpenHab listen to my lighting system as I want to insure that the buttons states are in sync with one another…if someone presses a wall dimmer switch I want OpenHab to show that the switch is ON.

My lighting control system “Vantage” will report button states via TCP, the same way I am talking to the system…

So if the system broadcasts

RGS 1 2 4 1/r
(fourth switch on master 1 of station 2 is ON)

I want to be able to update a switch in OpenHab as being on.

Do I write this as a rule or as something else? If the switch was called HALLWAY how would the syntax look?

All help much appreciated.

[rlkoshak (Rich Koshak)]

I think you can do this all within the Item binding config. It would look something like:

Switch Hallway { tcp="<[192.168.1.123:1234:'MAP(vantage.map)'], >[Your outgoing binding config here] ", autoupdate="false" }

Where:

• 192.168.1.123:1234 is the IP address and port of the device
• vantage.map is a map file in your transform folder containing a mapping between the String the Vantage devices are sending and ON and OFF states.

vantage.map would contain an entry for each device along the lines of:

RGS 1 2 4 1\r=OFF
RGS 1 2 4 1\r=ON

Note: You may need to experiment with quotes in the map file because of the spaces.

[KidSquid (The Squid)]

@rlkoshak

Rich - Thank you for your continued support.

I think I am close but missing something…

This is the item I have created.

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

When I click the switch, the lights come on and I can see a response from the Vantage lighting control system come back to OH. (FYI-The return code I mentioned in my previous post was incorrect…its not RGS, it’s SW) I see an error, stating that it could not find a mapping for the return code from Vantage. What’s strange is that it’s referencing the MAP file for the outbound connection, not the inbound connection.

As you can see in the ITEM above, the outbound mapping is done through 90.map while the inbound mapping should be done through m90.map. The m90.map file is in the same directory as 90.map yet it seems to be ignored.

Here’s a post from the log…the map file is highlighted in yellow.

Any thoughts???

Sid

[rlkoshak (Rich Koshak)]

I’ve no idea what is going wrong. Frankly, this is one reason why I tend to avoid Items with lots of binding configs. I usually set up separate Items, one for incoming and one for outgoing and a proxy switch. Then I use rules to keep everything in sync. It is a lot more code but it is way easier to troubleshoot problems.

I’m really no help here.

[KidSquid (The Squid)]

@rlkoshak

Thanks for your thoughts. You’ve really helped me with most of the challenges I’ve faced learning OH.

Can you point me in the direction of a proxy switch example I could copy and deploy?

Thanks,

squid

[rlkoshak (Rich Koshak)]

Automation/Orchestration Design Patterns

As a guy who’s written code for a living for 35+ years, I appreciate the “mother of all rules” post on the wiki and the discussions here which use groups for reduce lines of code. But I’ve not seen too much on doing systematic coordination/orchestration of automation events and design patterns of logic for same. So, I offer the following. This starts with my particular use case involving a Light in my kitchen. There’s a switch in the room to control the light, as well as a motion sensor whi…

This is the original posting and perhaps a little complex for your needs.

A Proxy Item is just an Item not bound to anything. So you would have:

items

Switch HallwayCommand { tcp=">[ON:10.5.1.6:3040:'MAP(90.map)'],>[OFF:10.5.1.6:3040:'MAP(90.map)'] " }
Switch HallwayUpdate { tcp="<[10.5.1.6:3040:'MAP(m90.map)']" }
Switch HallwayProxy

Rules

// when the proxy receives a command, send it to the device
rule "HallwayProxy received command"
when
    Item HallwayProxy received command
then
    HallwayCommand.sendCommand(HallwayProxy.state)
end

// when the Update Item receives a command, update the Proxy
rule "HallwayUpdate received command"
when
    Item HallwayUpdate received command
then
    HallwayProxy.postUpdate(HallwayUpdate.state)
end

Put HallwayProxy on your sitemap and only use HallwayProxy in the rest of your rules.

[KidSquid (The Squid)]

@rlkoshak

Rich - Can’t begin to say thank you enough for you guidance with this…

I have copied the code sample above and am getting an error in OH designer when I created a rules file.

The error description is:

Can you give a bit more guidance?

Also you stated earlier “only use HallwayProxy in the rest of your rules” I’m not following you…are you stating to use that for all of the other lighting switches? Sorry just a bit lost.

Squid

[rlkoshak (Rich Koshak)]

I’m not sure I understand this error. Does it work when it runs? Does it work when you use HallwayProxy.state.toString?

What really makes no sense is that the postUpdate in the next rule shows no error. Odd.

[KidSquid (The Squid)]

@rlkoshak

Hi Rich -

Again thank you for the continued support. I apologize for taking some time to get back with you, but I was called to Rio to assist some of my broadcast collagues with a couple of technical challenges…

Back to OH…

I made the change you reccomended above to HallwayProxy.state.toString which eliminates the error message in designer - but I still am having an issue with OH processing the message that comes back from the Vantage system. For some strange reason it wants to apply the outbound mapping file and not the incomming mapping file.

When I review the log file or watch the output of the command window I see all of the inbound messaging from the Vantage system referencing the outbound map file (90.map) not the inbound map file (m90.map)

Just to make sure everything looks legit, here is my item file:

Here is my sitemap:

Here is the outbound map (90.map):

Here’s the inbound map (m90.map)

And finally the rules file:

And just to make sure…here is the file structure:

Can you see any reason why the inbound traffic is getting read by my ourbound map??? Is there anything I am missing here?

Once again thank to the great community for your assistance!!

[rlkoshak (Rich Koshak)]

Add some logging to your rules just to see if there is somehow an interaction between the rules we are not accounting for.

It isn’t satisfactory, but try just using the one map file and put both sets of mappings in it and see if that works. That might fix the problem, though it won’t tell us why it is working wrong in the first place.

Are you sure the > and < are the right direction (I think they are but when it doesn’t work, question everything)?