KeenHome smart vent

[craigham]

Hi BobRak,

I have some Keenhome smart vents and I am trying to integrate them into openhab via Smartthings.

I don't see such a thing type, and discovery doesn't seem to find them. Unfortunately they are the only devices I have so it's kind of difficult for me to see if I am connecting correctly to the Smartthings Hub. I turned the debug up to TRACE, but still don't see logging when I do a device scan.

Question, can I dig into the thing-types.xml and put something together? The vent looks like it tase a few sensors, and a level item to control how open the vent is. Would the code inside the binding work for these standard type attributes, or does the vent also have to be defined within the java? Or could I create some type of generic thing and add channels for each of the attributes? I tried to attach a screen shot of the attributes as shown via developer portal for the hub.

thanks, Craig

[BobRak]

I believe you can dig into the thing-types.xml but you can not add or change the name of the existing things as they are referred to elsewhere in the binding and would need that files changed and a rebuild.

But, at this point it seems that you may not be correctly configured because a number of the states you show should have been discovered. Are you sure you have done everything in this configuration document. Especially the last step titled Configuration in the Smartthings Classic App? If so you should at least be able to check the temperature, switch and battery items. And, then they should appear in openHAB discovery.

[BobRak]

Do you have any more questions or can I close this request?

[craigham]

Hi Bob,

I thought i followed the directions, but will do it again before i bug you. It's good to know discovery should find the items.

please close.

thanks, craig

On Tue, 7 Jul 2020 at 10:48, Bob Raker notifications@github.com wrote:

Do you have any more questions or can I close this request?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/BobRak/OpenHAB-Smartthings/issues/94#issuecomment-655022735, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACXGUXTUFS52YCYA5OZIE7LR2NNYHANCNFSM4OPDCYKA .

[craigham]

@BobRak how important is the device network id for the Openhab device? I ask because I run openhab in docker. I used the Mac address of the docker host, but with virtual networking, that may be incorrect.

thanks Craig

[craigham]

@BobRak I don't think I am getting discovery to run.

I have changed the log level: openhab> log:list | grep smartthin org.openhab.binding.smartthings │ TRACE

However, when I run discovery from paper, or initiate from Karaf, I don't see the trace

logger.debug("Discovery background scanning job started");

openhab> bundle:list | grep Smart 264 │ Active │ 80 │ 2.5.5.202006262252 │ openHAB Add-ons :: Bundles :: Samsung Smartthings Binding

Would you have an ideas? Thanks in advance. Craig

[craigham]

@BobRak I believe I pretty much have it working now. Missed a step in the install directions.

[BobRak]

Craig:

Thanks for letting me know that you have it working. It does have a long and complicated setup process. I wish there was a way to make it simpler but that isn't possible right now. In the future I think the new Smartthings platform will support an easier integration. I've started looking at it but unfortunately right now it is very poorly documented so it is hard to figure out where to start. I'll keep watching how it is maturing.

Bob

[craigham]

Bob, I do have another question for you. Discovery doesn't seem to work, but I have been able to manually add things for the sensors for the smart vent. However, overall it is not how I would have expected it. I was expecting the various sensors (temp, open/close sensor, open level, and battery to be channels within a overall type representing the vent. Does this make sense to you? I have done work on a few bindings (omnilink, isy, russound-rnet) and that is how the things/channels/items was set up. Is there something in Smartthings which precludes this? Because I do find it intuitive/helpful to think of the actual device having various sensors, etc and keep the relationship.

Or is this because my discovery is not working?

thanks, Craig

[BobRak]

I suspect this has something to do with discovery not working.

HTTP Protocol Normally with http the client (openHAB) would send a message to a server (Smartthings hub). The hub would process the request and send back the response with an HTTP 200 code. Smartthings works differently. openHAB sends a request and Smartthings immediately responds with an HTTP 202 (Accepted). Then when Smartthings has an answer it starts a new conversation to openHAB and send the response. Smartthings uses the mac, ip and port to figure out where to send the response.

openHAB to Smartthings messages So, when you turn on a switch you would expect to see this in the log:

Sent message "{"capabilityKey": "switch", "deviceDisplayName": "Office Light", "capabilityAttribute": "switch", "value": "on"}" with path "/update" to the Smartthings hub, recieved HTTP status 202 (This is the normal code from Smartthings)

Smartthings to openHAB messages When Smartthings has processed the request it will send back a response like:

Smartthing servlet processing "state" request. data: {"capabilityAttribute":"switch","deviceDisplayName":"Office Light","hubEndTime":1594240274781,"hubTime":49,"value":"off"}

Note unfortunately this message is a TRACE level.

You would also see these messages if you turn on a light using the Smartthings app.

If you are not seeing these state messages then there is a problem with Smartthings sending messages to openHAB. Maybe this has to do with your mac address and Docker. I've not used Docker so I can't help there.

thing-types and channels Re your comment I was expecting the various sensors (temp, open/close sensor, open level, and battery to be channels within a overall type representing the vent. Yes, that does make sense. If you look at the Smartthing Capability Reference you will see for the most part each Capability (i.e. thing) has one Attribute (i.e. channel). I followed that pattern and did give some thought to adding my own thing-types that represent larger things, such as washing machines, air conditioners, etc. The problem is that everything will have a different set of attributes that I have no idea about. So, I didn't do anything. You could add your own thing-types but unfortunately that would require a recompile because the thing-types are referred to in the SmartthingsBindingConstantrs.java file.

[craigham]

I believe I do have 'reasonable' communication set up between the hub and openhab now. I will poke around some more at what could be going awry with discovery.

here is an example from my log file

Smartthing servlet processing "state" request. data: {"capabilityAttribute":"temperature","deviceDisplayName":"Keen Home Vent","hubEndTime":1594252188491,"hubTime":23,"value":"23.6"} 2020-07-08 16:49:48.545 [TRACE] [rtthings.internal.SmartthingsServlet] - Smartthings servlet returning. 2020-07-08 16:49:48.545 [TRACE] [rnal.handler.SmartthingsThingHandler] - Smartthings updated State for channel: smartthings:temperatureMeasurement:vent1:temperature to 23.6

Yes, interesting problem regarding types, channels, items etc for something seemingly as generic as what you must support. I hesitate to offer an opinion as admittedly I just got this working, and actually just added Smartthings to my home automation. However, it seems that there is some keying done on the name of the device...ie I have only added one of my keen smart vents to Smartthings, and when I look at the openhab smart app it seems to show each sensor with that same name in a section for the sensor type. I'm kind of thinking out loud, but maybe there would be value in a generic Smartthings thing type which could aggregate those various sensors, and use channels. I think that would be a nice for when say a battery dies in a device, it would be more intuitive writing rules to figure out why battery powered devices aren't working, etc.

I'll continue getting things integrated and if I actually think I have an idea of value for you, be sure to let you know.

nice work on the binding. I can see it was a complicated device to connect to and feel for you in inevitably handholding many users through the installation.

cheers, Craig

[BobRak]

With regards to there not being a better set of thing-types that include the typical channels for various appliances. That is something I could attempt to add at some point in the future. Also, it looks like it will be added to openHAB soon so maybe someone else will want to take that on.

In the end all that it really means is that you have to have many things for one appliance. Same number of items but they will each refer to a different thing. But what really matters is how it appears to the end user and that is controlled by the sitemap and there you can group things how you want.

Bob