Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add Russound Binding #1250

Merged
merged 13 commits into from
Jan 5, 2017
Merged

Add Russound Binding #1250

merged 13 commits into from
Jan 5, 2017

Conversation

tmrobert8
Copy link

Implementation of new Russound binding (RIO)

Signed-off-by: Tim Roberts [email protected] (github: tmrobert8)

@kaikreuzer kaikreuzer added the new binding If someone has started to work on a binding. For a new binding PR. label Sep 21, 2016
@tmrobert8
Copy link
Author

Kai,

Do you know what the issue is with this one (when I try to click on details - I get a 404 error)? I can merge both of those commits into one - but I doubt that's the issue

Thanks,
Tim

@tmrobert8
Copy link
Author

Well I merged the two commits and along the way noticed that I had a case issue (local was 1225-Russound but I had two remote ones "1225-russound" and "1225-Russound"). Removed the lowercase one and force pushed the other. Looks like one or the other corrected the issue...

@tmrobert8 tmrobert8 force-pushed the 1225-Russound branch 2 times, most recently from 3e037ca to 7b5d212 Compare October 7, 2016 15:06
@Tomtibo
Copy link

Tomtibo commented Oct 10, 2016

Here is the new RIO API documentation.
I'm not sure if it's better to continu the discussion here, or on openhab forum...
I will give you news from my testing!
RIO+Protocol+for+Third+Party+Integrators .pdf

@kaikreuzer
Copy link
Member

@tmrobert8 Before I go about reviewing this one - please let me know, if it is in a state to do so :-)

@tmrobert8
Copy link
Author

Feel free to review - I have some minor changes and wanted to address the issue of the mca88x but a review will catch anything else (probably similar comment that you posted on the atlona one).

Note: I had to wipe my pc and reload (rebuilding the openhab dev environment now) so it may take me awhile to get around to fixing these things

@tmrobert8
Copy link
Author

FYI - this should have conflicts now. I was using the bridgeHandlerInitialized, which seems to have been removed (via smarthome#2087). I'll need to update anyway to fix this - but welcome any other comments you have.

…-addons into 1225-Russound

# Conflicts:
#	addons/binding/org.openhab.binding.russound/ESH-INF/thing/thing-types.xml
#	addons/binding/org.openhab.binding.russound/META-INF/MANIFEST.MF
#	addons/binding/org.openhab.binding.russound/OSGI-INF/RussoundHandlerFactory.xml
#	addons/binding/org.openhab.binding.russound/src/main/java/org/openhab/binding/russound/RussoundBindingConstants.java
#	addons/binding/org.openhab.binding.russound/src/main/java/org/openhab/binding/russound/internal/RussoundHandlerFactory.java
#	addons/binding/org.openhab.binding.russound/src/main/java/org/openhab/binding/russound/internal/net/SocketSession.java
#	addons/binding/org.openhab.binding.russound/src/main/java/org/openhab/binding/russound/internal/net/SocketSessionListener.java
#	addons/binding/org.openhab.binding.russound/src/main/java/org/openhab/binding/russound/rio/AbstractBridgeHandler.java
#	addons/binding/org.openhab.binding.russound/src/main/java/org/openhab/binding/russound/rio/AbstractRioProtocol.java
#	addons/binding/org.openhab.binding.russound/src/main/java/org/openhab/binding/russound/rio/AbstractThingHandler.java
#	addons/binding/org.openhab.binding.russound/src/main/java/org/openhab/binding/russound/rio/RioConstants.java
#	addons/binding/org.openhab.binding.russound/src/main/java/org/openhab/binding/russound/rio/RioHandlerCallback.java
#	addons/binding/org.openhab.binding.russound/src/main/java/org/openhab/binding/russound/rio/StatefulHandlerCallback.java
#	addons/binding/org.openhab.binding.russound/src/main/java/org/openhab/binding/russound/rio/bank/RioBankConfig.java
#	addons/binding/org.openhab.binding.russound/src/main/java/org/openhab/binding/russound/rio/bank/RioBankHandler.java
#	addons/binding/org.openhab.binding.russound/src/main/java/org/openhab/binding/russound/rio/bank/RioBankProtocol.java
#	addons/binding/org.openhab.binding.russound/src/main/java/org/openhab/binding/russound/rio/controller/RioControllerConfig.java
#	addons/binding/org.openhab.binding.russound/src/main/java/org/openhab/binding/russound/rio/controller/RioControllerHandler.java
#	addons/binding/org.openhab.binding.russound/src/main/java/org/openhab/binding/russound/rio/controller/RioControllerProtocol.java
#	addons/binding/org.openhab.binding.russound/src/main/java/org/openhab/binding/russound/rio/favorites/RioFavoriteConfig.java
#	addons/binding/org.openhab.binding.russound/src/main/java/org/openhab/binding/russound/rio/favorites/RioFavoriteHandler.java
#	addons/binding/org.openhab.binding.russound/src/main/java/org/openhab/binding/russound/rio/favorites/RioFavoriteProtocol.java
#	addons/binding/org.openhab.binding.russound/src/main/java/org/openhab/binding/russound/rio/preset/RioPresetConfig.java
#	addons/binding/org.openhab.binding.russound/src/main/java/org/openhab/binding/russound/rio/preset/RioPresetHandler.java
#	addons/binding/org.openhab.binding.russound/src/main/java/org/openhab/binding/russound/rio/preset/RioPresetProtocol.java
#	addons/binding/org.openhab.binding.russound/src/main/java/org/openhab/binding/russound/rio/source/RioSourceConfig.java
#	addons/binding/org.openhab.binding.russound/src/main/java/org/openhab/binding/russound/rio/source/RioSourceHandler.java
#	addons/binding/org.openhab.binding.russound/src/main/java/org/openhab/binding/russound/rio/source/RioSourceProtocol.java
#	addons/binding/org.openhab.binding.russound/src/main/java/org/openhab/binding/russound/rio/system/RioSystemConfig.java
#	addons/binding/org.openhab.binding.russound/src/main/java/org/openhab/binding/russound/rio/system/RioSystemHandler.java
#	addons/binding/org.openhab.binding.russound/src/main/java/org/openhab/binding/russound/rio/system/RioSystemProtocol.java
#	addons/binding/org.openhab.binding.russound/src/main/java/org/openhab/binding/russound/rio/zone/RioZoneConfig.java
#	addons/binding/org.openhab.binding.russound/src/main/java/org/openhab/binding/russound/rio/zone/RioZoneHandler.java
#	addons/binding/org.openhab.binding.russound/src/main/java/org/openhab/binding/russound/rio/zone/RioZoneProtocol.java
…nto 1225-Russound

# Conflicts:
#	addons/binding/pom.xml
Copy link
Member

@kaikreuzer kaikreuzer left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks, that is a HUGE binding...
I stop my review for the moment as I would like to ask for some refactoring of the modelling - mainly introducing specific channel types instead of your "shortcut". This should hopefully not have much impact on the Java code, mainly only on the XML files, so I hope that change won't be too much effort for you. I'll continue the review after your next update. Please also do not forget the feature.xml!

xsi:schemaLocation="https://eclipse.org/smarthome/schemas/binding/v1.0.0 https://eclipse.org/smarthome/schemas/binding-1.0.0.xsd">

<name>Russound Binding</name>
<description>This is the binding for Russound.</description>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

could you add a few words about what Russound is?

@@ -0,0 +1,11 @@
# binding
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

remove this file

<description>Ethernet access point to Russound RIO control system (usually the main controller)</description>

<channels>
<channel id="version" typeId="readonlystring"><label>Firmware Version</label><description>Firmware Version</description></channel>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

firmware version should be added as a property, not as a channel

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Question for you (have never used properties before). Can I set a property at any time? All these 'channels' are information I get AFTER the plugin is initialized fully (and I start getting responses from the system)...

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, anytime! Whenever you first get hold of the information. If the Thing is stored in a database (and not defined in a *.things file), it will even be persisted.

<label>IP or Host Name</label>
<description>The IP or host name of the Russound RIO access point</description>
</parameter>
<parameter name="ping" type="integer" required="false">
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

mark as advanced

<description>The ping interval in seconds to keep the connection alive</description>
<default>30</default>
</parameter>
<parameter name="retryPolling" type="integer" required="false">
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

mark as advanced


<channels>
<channel id="type" typeId="readonlystring"><label>Model Type</label><description>Model Type</description></channel>
<channel id="ipaddress" typeId="readonlystring"><label>IP Address</label><description>IP Address</description></channel>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hm, is this any different from the IP adress of the bridge? Anyhow, as this is not changing dynamically, it should merely be added as a property, if at all.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually - I'm not sure about this one (that's why I left it in). The API seems to indicate they can be (why else would they provide two different ip addresses). However, in my system they are one and the same (one controller is they system interface and controls all other controllers). However, the X-Series (which I do NOT own) is more decentralized and may be the reason for this. Since I definitively don't know - I'd rather leave it (although I do agree that making it a property is best).

</config-description>
</thing-type>

<channel-type id="string">
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I strongly suggest to remove the types string, readonlystring and button.
Channel types should express a certain functionality - which can be very different for the different channels.
Reusing a type is really only meant for situations, where you have 1..n of the very same functionality, e.g. zones to control.

<label>Russound Zone</label>
<description>Zone within a Controller</description>

<channels>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

make sure that only a few are regular channels and the majority are advanced channels.

<label>Russound Source</label>
<description>Source (tuner, streamer, etc) within the Russound System</description>

<channels>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

make sure that only a few are regular channels and the majority are advanced channels.


The following configurations occur for each of the bridges/things:

### Russound System
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

add an empty line after every headline

@tmrobert8
Copy link
Author

hah - think this is huge - wait until you see the sony one (much bigger!). I'll address the things you've mentioned (in addition to some of the stuff you mentioned in other ones) and recommit (doubtful until next week however). Most of it's XML - so no big deal. I've never worked with properties - but I'll look into it. Not sure what you meant about the 'features.xml' (have no idea what that is).

@kaikreuzer
Copy link
Member

Not sure what you meant about the 'features.xml' (have no idea what that is).

Very easy to explain: This file: https://github.com/openhab/openhab2-addons/blob/master/features/openhab-addons/src/main/feature/feature.xml
Adding your binding in there makes it being picked up by the distro - otherwise it will be missing!

@tmrobert8
Copy link
Author

Ah - that would seem rather important then :)

I'll add it (and do the same for the atlona and sony one in their commits)

Removed @ids, changed some channels to be properties, updated comments,
fixed channel types, fixed issue with mca88x, implemented new
socketchannel, fixed issue with reconnecting when network drops
@tmrobert8
Copy link
Author

Kai,

I believe I got everything you mentioned in your review (and we solved the mca88x issue - very happy with that). Feel free to do "review 2"

Tim

@kaikreuzer
Copy link
Member

You are much too fast for me! I won't find the time to review 6000+ LOC in this year anymore - but maybe next year ;-)

Copy link
Member

@kaikreuzer kaikreuzer left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi Tim,

I only did a rough review, but the code looks overall very clean.

One general remark, though: I am not too happy about the Thing modelling, which appears to me pretty fine-grained. Note that the idea of a "Thing" is to represent a (typically physical) unit that can be individually added and removed from the system. It is not meant as a means to structure the features of a single device.

While it might be ok to say that a "zone" and a "source" is a kind of virtual device that should be modelled that way, I think this is not ok for banks, favorites and presets. These should rather be modelled as channel groups, which are dynamically added by the handler to the according Thing. Would that be possible or am I overlooking something?

## Full Example

The following is an example of
1. Main controller (#1) at ipaddress 192.168.1.24
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

add empty line above

```

.sitemap
```
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

add empty line above

@@ -0,0 +1,461 @@
# Russound Binding

This binding provides integration with any Russound system that support the RIO protocol (all MCA systems, all X systems). This binding provides compatibility with RIO Protocol v1.7 (everything but the Media Managment functionality). The protocol document can be found in the Russound Portal ("RIO Protocol for 3rd Party Integrators.pdf"). Please update to the latest firmware to provide full compatibility with this binding. This binding does provide full feedback from the Russound system if events occur outside of OpenHAB (such as keypad usage).
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

openHAB, not OpenHAB!

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lol - Stupid Fingers like to Capitalize

throw new IllegalArgumentException("command cannot be null");
}

// if (command.trim().length() == 0) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can this be removed?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That whole class will be removed very shortly (I've been testing the SocketChannelSession implementation and it appears pretty stable).

public void bridgeStatusChanged(ThingStatusInfo bridgeStatusInfo) {
if (bridgeStatusInfo.getStatus() == ThingStatus.ONLINE) {
if (getThing().getStatusInfo().getStatus() != ThingStatus.ONLINE) {
dispose();
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do you really have to dispose and reinitialize the handler instance itself? Note that this should usually only be called by the framework and once a handler is initialized it should stay this way.
Instead, it would be nicer to only tell the handler that it should to a "reconnect"/"resyncWithBridge" or whatever.

initialize();
}
} else if (bridgeStatusInfo.getStatus() == ThingStatus.OFFLINE) {
dispose();
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, don't dispose. This means the handler is not in a working state anymore (while the framework might still pass commands to it).

public void bridgeStatusChanged(ThingStatusInfo bridgeStatusInfo) {
if (bridgeStatusInfo.getStatus() == ThingStatus.ONLINE) {
if (getThing().getStatusInfo().getStatus() != ThingStatus.ONLINE) {
dispose();
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

same comment as on the AbstractBridgeHandler

* @param resp a possibly null, possibly empty response
*/
private void handleFailureNotification(Matcher m, String resp) {
logger.info("Error: " + resp);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

use parameterized logging.
Is it relevant to the regular user? If not, reduce to debug

<feature name="openhab-binding-samsungtv" description="Samsung TV Binding" version="${project.version}">
<feature>openhab-runtime-base</feature>
<feature>openhab-transport-upnp</feature>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why did you remove this line?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ack! Meant to remove that line from the russound one! I'll revert that one...

* which accompanies this distribution, and is available at
* https://www.eclipse.org/legal/epl-v10.html
*/
package org.openhab.binding.russound.rio.bank;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You should move all subpackages of org.openhab.binding.russound.rio to org.openhab.binding.russound.internal as none of them is exported (and probably should not be considered as a public API).

@tmrobert8
Copy link
Author

I'll make all these changes (need to look into the dispose stuff more - I need to send some commands to RIO on dispose and need to make sure those still happen).

Zone/Sources are definitely physical based (you can physically add more zones and more sources to the system). I agree that favorites/banks/presets are 'murky' (especially favorites). Why they are murky is that, while they are not physical, they are virtual in that you can add/remove them from the system (via russound's setup application). Ex: I can create a bank #3 (without banks #1, #2 being defined) with presets (#2 and #4) on controller #2 then add bank#3.preset#4 as favorite #2 on zone #6 on controller #2. When all was said and done, it seems easier to set them up as things because you can set openHAB in the exact same manner as you do in the application. What's your thought on that?

@tmrobert8
Copy link
Author

tmrobert8 commented Jan 3, 2017

This discussion got me to go back and reread about channel groups - which I have not used yet and I'm still a bit unfamilar with it. On that page it states "A thing can only have direct channels or channel groups, but not both". Is that true? If so - that would be a show stopper as well (since a bank is assigned to a zone which has many other direct channels on it. This would also seem to be a HUGE limitation to using channel groups (thinking of the atlona [hdbaset matrix switch] addon - the inputs/outputs could easily be modelled as channel groups (and would really simplify the addon) - but I'd need to mix those in with the other direct channels [power, etc]) and that statement seems to indicate it can't be mixed in.

@kaikreuzer
Copy link
Member

that statement seems to indicate it can't be mixed in.

No, I guess you misinterpret that. It is true that you have to decide for a Thing whether you want to use channel groups or not. If you use groups (because you need it for the banks), you would simply put all the "individual" channels into a "general" or "other" group.

@kaikreuzer
Copy link
Member

it seems easier to set them up as things because you can set openHAB in the exact same manner as you do in the application.

Question: Can the handler read all of this setup from the russound server (i.e. the number of banks and their ids) or does the user really have to replicate this setup manually in his Thing definitions and needs to keep them in sync manually?

@tmrobert8
Copy link
Author

Currently, user needs to keep in sync. I could infer it by API side effects (get "name" for controller[1].zone[1].bank[1] - no name, doesn't exist). I'm pretty sure that's how the native application does it and it takes that application about 5 minutes to scan through my whole system.

Eventually I wanted to put all this into a discovery process (port scan for the controller - then run through the API to discover what is or isn't setup). That would take care of the initial setup - but if they modify an already setup system, there really is no way to detect any changes short of doing a full scan again (which is probably too intensive to do on a regular basis).

@tmrobert8
Copy link
Author

tmrobert8 commented Jan 3, 2017

This probably should be taken out of this discussion - but wanted to run this past you. Let's say I change the bank into a channel group. The zone would then have a channel-group "primary" which defines all the direct channels and then zero-to-many bank groups:

...
<channel-group id="primary" typeid="primary"/>
<channel-group id="bank1" typeid="bank"/>
<channel-group id="bank2" typeid="bank"/> 
...
<channel-group-type id="bank">
   <label>Russound Bank</label>
   ...
   <channels>...the generic bank channels (name, etc)</channels>
</channel-group-type>

A few questions:

  1. How do we identify that "bank1" is russound bank id of 1 short of parsing the identifier from the channel's id? With channel-type - I could identify it through channel config or possibly the tag - but channel-group-type doesn't seem to have those options?
  2. How would I model presets (which would be channel groups within a bank)? Doesn't appear that the channel-group-type allows embedded channel-group(s)?
  3. I'd have no idea how to model favorites - which a attached to an individual preset but assigned to either the system or zone and can be changed via the API (added or removed)

@kaikreuzer
Copy link
Member

  1. You will have to check it through the channel id, which will be "bank1#somechannel".
  2. Correct, there is only one level, you cannot put groups into groups. You would add a simple "favorite" channel to your bank group (as a dynamic channel, which isn't define in the group type).
  3. Having a closer look at it, I would suggest to heavily reduce the number of channels. It seems as if you have defined a channel for every possible command. Instead, I would create a single "favorite" channel that has StringType and which provides the list of available favorite names as options. Sending a string would then do a "restore" of the favorite. I would leave save&delete out of scope, this is probably rather something the user would do through the dedicated app, not necessarily through openHAB.

@tmrobert8
Copy link
Author

Kai,

The problem is - I use all that functionality (that's why I wrote it in). Example: presets and favorites are modified based on room presence (ie my wife's presets/favorites follow her around, as do mine and my sons).

If you don't mind, I'm going to leave this one alone - I really think the way I have it modeled is the way the RIO system is put together and it feel less like 'forcing' the channel grouping onto it.

I will however be modifying the atlona binding to use channel groupings - the input/outputs are much better modeled with channel groups rather than how I have it now.

Tim

@kaikreuzer
Copy link
Member

presets and favorites are modified based on room presence

So you are never together with your wife in the same room? ;-)

Well, ok, I don't have a Russound, so I cannot really assess how it is all set up and used, so let's keep your implemented modelling.
Nonetheless, you might think about combining the save/delete/restore channels into one "command" channel that takes predefined command (using "OFF" for "zone favorite" is really ugly...). After all, for none of these channels, a state makes any sense, so there is no reason for having them as separate channels.

@tmrobert8
Copy link
Author

Kai - just committed all the changes that should address these notes. BTW - excellent suggestion on the command channels - makes alot more sense that way (not sure why I didn't think about it).

@tmrobert8
Copy link
Author

tmrobert8 commented Jan 4, 2017

Latest build - fixes MCA88 commands. Please note that alot of changes have happened to the channels since the last posting (alot are now properties, many channel type changes).

Latest build 2 - changed from a basic socket implementation to a socket channel implementation and fixed issue reconnecting if network drops

Latest build 3 - fixed issue with warning message during disconnnect, fixed issue when reloading configuration.

Latest build 4 - implemented many of the changes from the review.

org.openhab.binding.russound-2.0.0-SNAPSHOT.jar.zip

Copy link
Member

@kaikreuzer kaikreuzer left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks! Unfortunately, github shows almost all files as being completely changed on your last commit, so it is hard for me to do a diff review. I therefore just trust you that you have properly addressed my comments - a quick scan looks good to me!

So only one very small comment left, see below.

org.slf4j
Service-Component: OSGI-INF/*.xml
Export-Package: org.openhab.binding.russound,
org.openhab.binding.russound.rio
org.openhab.binding.russound.internal.rio
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

no, you should not export it anymore now :-)

@tmrobert8
Copy link
Author

Done - you may want to hold off on the actual merge until Tom tests using his mca-88x. I'll post a message when he seems good with it (modifying the atlona addon right now with all the comments and changes - don't bother reviewing that one)

@Tomtibo
Copy link

Tomtibo commented Jan 5, 2017

Hi! I've tested the latest snapshot and all is working fine with the mca-88x! I've not tested favorites and banks, I don't know how or if they works with the mca-88x. Nice work guys!!

@tmrobert8
Copy link
Author

Kai,

Feel free to merge then!

Tim

@kaikreuzer kaikreuzer merged commit 717b905 into openhab:master Jan 5, 2017
@kaikreuzer
Copy link
Member

Thanks again!

@kaikreuzer kaikreuzer modified the milestone: 2.0.0 Jan 17, 2017
fharni pushed a commit to fharni/openhab2-addons that referenced this pull request Feb 10, 2017
* Initial Russound Implementation (openhab#1225)

Signed-off-by: Tim Roberts <[email protected]>
@tmrobert8 tmrobert8 deleted the 1225-Russound branch July 31, 2018 12:40
markus7017 pushed a commit to markus7017/openhab-addons that referenced this pull request Aug 12, 2023
* Update README (2.5.x) (openhab#1153)

Change branch name.

Signed-off-by: Yannick Schaus <[email protected]>

* Update items.md (openhab#1156)

* Added var and VA units to UoM (openhab#1146)

VA (Volt-Ampere - apparent power) and var (Volt-Ampere reactive) are used to measure power and energy consumption in AC circuits.


Signed-off-by: Nagy Attila Gabor <[email protected]>

* Fix filepath to keystore (openhab#1148)

Default openHAB userdata environment variable should be `$OPENHAB_USERDATA`, not `$USER_DATA` shouldn't it? At least, this is the default on my fresh openHABian and also the most popular variant to find in the docs.

* Slight language corrections (openhab#1150)

I think it reads better this way

Signed-off-by: Richard Davies <[email protected]>

* additional example for non default persistence service (openhab#1152)

For me it was confusing how to pass on the serviceId into methods that already had an argument. An extra example is always good.

Signed-off-by: jaco <[email protected]>

* Adding 12 new logos for OH Add-Ons page on website (openhab#1158)

Signed-off-by: bracklanna [email protected]

* Added missing preset variables (openhab#1104)

* Added missing preset variables

Signed-off-by: Scott Rushworth <[email protected]>

* Cleaned up blank lines, fixed table, and added file name for SimpleRule

Signed-off-by: Scott Rushworth <[email protected]>

* Fix broken link (openhab#1165)

* Added Hotlink from "label" section to "state presentation" (openhab#1167)

* Added note about broken action (openhab#1164)

* Added note about broken action

See openhab/openhab-core#1374

Signed-off-by: Christoph Weitkamp <[email protected]>

* Incorporated changes from review

Signed-off-by: Christoph Weitkamp <[email protected]>

* Incorporated changes from review

Signed-off-by: Christoph Weitkamp <[email protected]>

* Update index.md (openhab#1170)

Link appears to be wrong and does not work when I click on it in Edge. Loads the same page again instead of loading the correct new page from the hyperlink.

https://www.openhab.org/docs/developer/guidelines.html

* Added Airthings logo (openhab#1171)

* typo in exambp (openhab#1172)

`Temperature.averageSince(now.minusMinutes(5),"influxdb")`

* file.encoding=UTF-8 (openhab#1173)

* Update demo URL and add demo.rules URL (openhab#1174)

Based on: https://community.openhab.org/t/demo-setup-missing/94850
Old Link is broken leading to 404.
The link to the demo.rules on github is an extra :)

* Replace outdated zulu.org link. (openhab#1177)

* Replace outdated zulu.org link.

As of 3/23/2020 zulu.org has an SSL cert that expired on 9/28/2019. Changed link to azul.com/downloads, since that appears to be the new official source.

Signed-off-by: Billy Stevens <[email protected]>

* Changed all http links to https for installation/index.md.

All changed links working, tested on 3/24/2020.

Signed-off-by: Billy Stevens <[email protected]>

* Minor language tweak (openhab#1178)

* Ending an active scan/stopScan (openhab#1179)

Signed-off-by: Mark Theiding <[email protected]>

* Add files via upload (openhab#1184)

* Update persistence.md (openhab#1185)

Clarify return objects for max/min rules extensions.

Signed-off-by: Ross Kennedy [email protected]

* Update things.md (openhab#1186)

Amended example code to include using label and location when defining a Thing with a bridge that is defined elsewhere.

* Correct typos (openhab#1190)

* Correct usage of its/it's

"It's" is always a contraction of "it is" or "it has".  "Its" is a
possessive.  Correct a few places where they were used backwards.

Signed-off-by: Bjorn Helgaas <[email protected]>

* Correct "Z-Wave" spelling

Per https://www.z-wave.com/, the canonical spelling appears to be "Z-Wave".
Most places use "Z-Wave" already; change the remaining references to match.

Signed-off-by: Bjorn Helgaas <[email protected]>

* Correct typos and grammatical errors

Correct some typos and grammatical errors.

Signed-off-by: Bjorn Helgaas <[email protected]>

* Update sitemap.md section charts (openhab#1191)

I observed that the unique first word in the labels of items charted in a group isn't causing an empty chart anymore. I'm on openHAB 2.5.1.

Signed-off-by: Juergen Baginski [email protected]

* Add image for insteon binding (openhab#1196)

Signed-off-by: Rob Nielsen <[email protected]>

* typo (openhab#1198)

Signed-off-by: Mark Theiding <[email protected]>

* Installation details (openhab#1197)

Added more details around the installation and configuration process.
Fixed that engine no longer logs "Activated scripting support..."

Signed-off-by: Mark Theiding <[email protected]>

* Update sitemaps.md (openhab#1202)

Added full item definition for usage of visibility. See https://community.openhab.org/t/sitemap-visibility-basic-ui/97304/9

* Updated ecobee logo (https://brand.ecobee.com/) (openhab#1203)

Signed-off-by: Rob Nielsen <[email protected]>

* tutorial: Fix description of sitemap 'type' (openhab#1204)

In the tutorial, the generic sitemap description says that ItemType has
to be the same as the type defined in default.items.
Looking at
https://www.openhab.org/docs/configuration/items.html#type and
https://www.openhab.org/docs/configuration/sitemaps.html#element-types
this is incorrect as they take different values.
The example is even mislading as `Switch` is one of the only types which
is common between items and sitemaps. Might be better to describe
`Default` instead.

Signed-off-by: Christophe Fergeau <[email protected]>

* Added information about DateTime Group functions LATEST/EARLIEST (openhab#1206)

Signed-off-by: Christoph Weitkamp <[email protected]>

* Add section for documentation contributions (openhab#1205)

Hopefully this will lower the hurdle for people to submit documentation contributions. I know from myself that I didn't submit various documentation improvements, because I didn't know git and thought it would be a much more involved process. 
Ideally there would be a separate documentation section, but submitting this under the development contribution page for now (as per discussion with @Confectrician in openhab/openhab-docs#1179 (comment)).
Note that I am addressing the issue of DCO failures wrt specifying the full name that I ran into myself in openhab/openhab-docs#1197 (comment). I found a good discussion of the issue at dcoapp/app#43.

Signed-off-by: Mark Theiding <[email protected]>

* fix typo (openhab#1209)

* add description of Ephemeris localization support (openhab#1210)

Add a new section to describe the localization support and how-to steps

Signed-off-by: Michael Roßner [email protected]

* Line 115 broken link - should be: (openhab#1217)

* Line 115 broken link - should be:

({{base}}/docs/configuration/sitemaps.html#element-types)

was:
({{base}}/configuration/configuration/sitemaps.html#element-types)

* Removed diplicated docs breadcrumb

Signed-off-by: Jerome Luckenbach <[email protected]>

Co-authored-by: Jerome Luckenbach <[email protected]>

* add missing space between words (openhab#1212)

* Update configuration.md (openhab#1215)

I'm a beginner myself. Though I liked this tutorial very much, it took me some time trying and erroring and finally reading forum posts to get behind this. I didn't even know there was something like a more modern ping. So maybe others are happy to learn this right from the beginning.

* Remove architecture from Docker tags (openhab#1220)

Docker automatically detects the architecture and downloads the appropriate image (openhab/openhab-docker#213).
BuildKit will no longer generate new tags having the architecture (openhab/openhab-docker#293).

Signed-off-by: Wouter Born <[email protected]>

* slight readability improvements (openhab#1221)

* slight readability improvements

* Update introduction.md

* Update introduction.md

* minor wording update

* Update eclipse.md (openhab#1225)

Clarifying that it's no longer possible to make changes in the Core Framework for 2.5.x.

Signed-off-by: Mark Theiding <[email protected]>

* [fmiweather] logo for FMI Weather binding (openhab#929)

Signed-off-by: Sami Salonen <[email protected]>

* Update eclipse.md (openhab#1226)

Added additional structure around install, run, debug and update steps. Provided more pointers to interactions with Eclipse, Maven and Git.

Signed-off-by: Mark Theiding <[email protected]>

* Update contributing.md (openhab#1227)

Need to escape \< and \> in the sign off message format so users see them explicitly in the Contributing to the Documentation section. 

Signed-off-by: Mark Theiding <[email protected]>

* Update contributing.md (openhab#1228)

Small refinement on documentation change submission flow. 

Signed-off-by: Mark Theiding <[email protected]>

* Add doc folder to the binding directory structure (openhab#1230)

Signed-off-by: Fabian Wolter <[email protected]>

* Make Subheadings Use Proper Subheading Syntax (openhab#1234)

This way they render out as proper markdown and don't look weird on the website

Signed-off-by: Stefan Zabka <[email protected]>

* Remove unnecessary isCancelled() from code example (openhab#1235)

Cancelling an already canceled task has no effect. IMHO this check is not necesssary and removal would simplify the code. I came to this because I saw this pattern in many bindings during reviewing.

Signed-off-by: Fabian Wolter <[email protected]>

* Update thing-xml.md (openhab#1236)

Signed-off-by: Christoph Weitkamp <[email protected]>

* Fix broken ESH links (openhab#1231)

Signed-off-by: Wouter Born <[email protected]>

* Update logging.md (openhab#1238)

Add information on how to find out the symbolic names of the bundles

* Remove Apache Commons from Default Libraries (openhab#1229)

See openhab#7722
Signed-off-by: Fabian Wolter <[email protected]>

* Update introduction.md (openhab#1239)

* Update introduction.md

Signed-off-by: Markus Storm [email protected]

* Update introduction.md

* Revise Java recommendations (openhab#1240)

* Revise Java recommendations

* Delete pine.md

Do not recommend PINE, it's not supported any longer by openHABian.

* Removed sidebar link in config

Signed-off-by: Jerome Luckenbach <[email protected]>

Co-authored-by: Jerome Luckenbach <[email protected]>

* Update security.md (openhab#1241)

Been using FreeDNS for many years (ever since all these companies got rid of their free tiers) and never an issue!

* Fix DecimalType hex conversion example (openhab#1243)

See: openhab/openhab-core#1526

Signed-off-by: Wouter Born <[email protected]>

* Fix typo (openhab#1244)

Signed-off-by: Wouter Born <[email protected]>

* Update persistence.md (openhab#1246)

Fixes link to quartz docs page.

* Revision. (openhab#1187) (openhab#1237)

* Revision. (openhab#1187)

- Update of screenshots, removal of old screenshots
- Chapters for better formatting
- Removal of ZWave chapter (one example of adding things should be enough IMHO)
- Adding items in simple mode and in "manual" mode

Signed-off-by: Sascha Billian <[email protected]>

* Use one line per sentence
Signed-off-by: Sascha Billian <[email protected]>

Co-authored-by: Jerome Luckenbach <[email protected]>

* Add notes for configuring Synology Diskstation (openhab#1219)

* Add notes for configuring Synology Diskstation

I have a working set up for SSL enabled remote access on a Synology diskstation, taking advantage of the GUI as much as possible, to ensure automatic renewal of certs from Let's Encrypt, etc. It took me about 8 hours to suss it all out, but it could be achieved in about 30 mins if you knew exactly what to do... may not be widely useful, but since Synology is officially supported, I figured this might be a good addition.

There's also a minor error in the 'allow' masks - these should be 192.168.0.0/24 to allow access to anything in the 192.168.0.xxx range.

* Updated to use one line per sentence

Updated to use one line per sentence - sorry for the delay!

* Update security.md

* Updated for one line per sentence

Updated for one line per sentence

Signed-off-by: Andrew Mills [email protected]

* Bad subnet (openhab#1245)

Nginx warns about low address bits of `192.168.0.1/24` because they are meaningless.
The correct subnet mask should be `192.168.0.0/24`

Signed-off-by: Olivier Béraud <[email protected]>

* Fixed broken images. (openhab#1247)

* Fixed broken images.

Signed-off-by: Jerome Luckenbach <[email protected]>

* Fix image path

Signed-off-by: Jerome Luckenbach <[email protected]>

* [documentation] clarification of representation property (openhab#1248)

* [documentation] clarification of representation property

Signed-off-by: Andrew Fiddian-Green <[email protected]>

* [documentation] typo

Signed-off-by: Andrew Fiddian-Green <[email protected]>

* [documentation] adopt suggestions of reviewers

Signed-off-by: Andrew Fiddian-Green <[email protected]>

* [documentation] commas

Signed-off-by: Andrew Fiddian-Green <[email protected]>

* [documentation] typo

Signed-off-by: Andrew Fiddian-Green <[email protected]>

* [documentation] addopted suggestions of @bobadair

Signed-off-by: Andrew Fiddian-Green <[email protected]>

* [documentation] typo

Signed-off-by: Andrew Fiddian-Green <[email protected]>

* [documentaion] example added back

Signed-off-by: Andrew Fiddian-Green <[email protected]>

* [documentaion] simplified text

Signed-off-by: Andrew Fiddian-Green <[email protected]>

* [documentation] typo

Signed-off-by: Andrew Fiddian-Green <[email protected]>

* [documentation] adopted reviewer comment

Signed-off-by: Andrew Fiddian-Green <[email protected]>

* Add Alexa mapping along side a channel mapping (openhab#1249)

* Add Alexa mapping along side a channel mapping

It took me a while to find this https://community.openhab.org/t/tagging-devices-for-alexa-support/98155/3 on the Forum and its not clearly documented in the openHAB Amazon Alexa Smart Home Skill or here in Item Metadata.
I originally suggested this as an update to the openHAB Amazon Alexa Smart Home Skill documentaion, but it fits better here, then other integrations using metadata (e.g. HomeKit or Google Assistant) could refer to it as well.

* Update items.md

* Mention defaults for element type setpoint. (openhab#1250)

Mention defaults for min, max and step value for element type setpoint.

Signed-off-by: Thomas Weiler <[email protected]>

* Update index.md (openhab#1251)

I thought 'workl' was probably intended to be 'work'.

* Items - Bedroom_Light written as Light_Bedroom (openhab#1252)

Fix small error which might mislead some readers.

* Added example for time-weighted averages (openhab#1253)

Signed-off-by: Christoph Weitkamp <[email protected]>

* Remove deprecated UIs, Eclipse Marketplace from sidebar

Signed-off-by: Yannick Schaus <[email protected]>

* Update branch name in README

Signed-off-by: Yannick Schaus <[email protected]>

Co-authored-by: Markus Storm <[email protected]>
Co-authored-by: Nagy Attila Gábor <[email protected]>
Co-authored-by: Christoph Thiede <[email protected]>
Co-authored-by: Richard Davies <[email protected]>
Co-authored-by: jwaes <[email protected]>
Co-authored-by: bracklanna <[email protected]>
Co-authored-by: Scott Rushworth <[email protected]>
Co-authored-by: cpmeister <[email protected]>
Co-authored-by: Ross Kennedy <[email protected]>
Co-authored-by: Christoph Weitkamp <[email protected]>
Co-authored-by: Skinah <[email protected]>
Co-authored-by: pali <[email protected]>
Co-authored-by: ljsquare <[email protected]>
Co-authored-by: PatrikG <[email protected]>
Co-authored-by: Elias H <[email protected]>
Co-authored-by: Billy Stevens <[email protected]>
Co-authored-by: theiding <[email protected]>
Co-authored-by: jadcx <[email protected]>
Co-authored-by: Bjorn Helgaas <[email protected]>
Co-authored-by: Jürgen Baginski <[email protected]>
Co-authored-by: robnielsen <[email protected]>
Co-authored-by: GumbyMan82 <[email protected]>
Co-authored-by: Christophe Fergeau <[email protected]>
Co-authored-by: Paulo "JCranky" Siqueira <[email protected]>
Co-authored-by: Michael Rossner <[email protected]>
Co-authored-by: BugSmurF <[email protected]>
Co-authored-by: Jerome Luckenbach <[email protected]>
Co-authored-by: josefscript <[email protected]>
Co-authored-by: Wouter Born <[email protected]>
Co-authored-by: Sami Salonen <[email protected]>
Co-authored-by: Fabian Wolter <[email protected]>
Co-authored-by: Stefan Zabka <[email protected]>
Co-authored-by: TRS-80 <[email protected]>
Co-authored-by: sihui <[email protected]>
Co-authored-by: Andrew Mills <[email protected]>
Co-authored-by: Olivier Béraud <[email protected]>
Co-authored-by: Andrew Fiddian-Green <[email protected]>
Co-authored-by: LeeC77 <[email protected]>
Co-authored-by: Thomas Weiler <[email protected]>
Co-authored-by: garretcook <[email protected]>
Co-authored-by: Michael Fielding <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
new binding If someone has started to work on a binding. For a new binding PR.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants