Add Russound Binding #1250
Add Russound Binding #1250
Conversation
kaikreuzer
added
the
new binding
|
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, |
tmrobert8
force-pushed
the
1225-Russound
branch
from
fbbfc3c to
2f4f031
Compare
|
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
force-pushed
the
1225-Russound
branch
2 times, most recently
from
3e037ca to
7b5d212
Compare
Signed-off-by: Tim Roberts <troberts@bigfoot.com>
tmrobert8
force-pushed
the
1225-Russound
branch
from
7b5d212 to
56e0f8f
Compare
|
Here is the new RIO API documentation. |
|
@tmrobert8 Before I go about reviewing this one - please let me know, if it is in a state to do so :-) |
|
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 |
|
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. |
Signed-off-by: Tim Roberts <troberts@bigfoot.com>
…-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
There was a problem hiding this comment.
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="http://eclipse.org/smarthome/schemas/binding/v1.0.0 http://eclipse.org/smarthome/schemas/binding-1.0.0.xsd"> | ||
|
|
||
| <name>Russound Binding</name> | ||
| <description>This is the binding for Russound.</description> |
There was a problem hiding this comment.
could you add a few words about what Russound is?
| @@ -0,0 +1,11 @@ | |||
| # binding | |||
| <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> |
There was a problem hiding this comment.
firmware version should be added as a property, not as a channel
There was a problem hiding this comment.
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)...
There was a problem hiding this comment.
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"> |
| <description>The ping interval in seconds to keep the connection alive</description> | ||
| <default>30</default> | ||
| </parameter> | ||
| <parameter name="retryPolling" type="integer" required="false"> |
|
|
||
| <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> |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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"> |
There was a problem hiding this comment.
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> |
There was a problem hiding this comment.
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> |
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
add an empty line after every headline
kaikreuzer
added
the
awaiting feedback
|
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). |
Very easy to explain: This file: https://github.com/openhab/openhab2-addons/blob/master/features/openhab-addons/src/main/feature/feature.xml |
|
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
|
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 |
|
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 ;-) |
kaikreuzer
removed
the
awaiting feedback
There was a problem hiding this comment.
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 |
| ``` | ||
|
|
||
| .sitemap | ||
| ``` |
| @@ -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). | |||
There was a problem hiding this comment.
lol - Stupid Fingers like to Capitalize
| throw new IllegalArgumentException("command cannot be null"); | ||
| } | ||
|
|
||
| // if (command.trim().length() == 0) { |
There was a problem hiding this comment.
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(); |
There was a problem hiding this comment.
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(); |
There was a problem hiding this comment.
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(); |
There was a problem hiding this comment.
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); |
There was a problem hiding this comment.
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> |
There was a problem hiding this comment.
why did you remove this line?
There was a problem hiding this comment.
Ack! Meant to remove that line from the russound one! I'll revert that one...
| * which accompanies this distribution, and is available at | ||
| * http://www.eclipse.org/legal/epl-v10.html | ||
| */ | ||
| package org.openhab.binding.russound.rio.bank; |
There was a problem hiding this comment.
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).
kaikreuzer
added
the
awaiting feedback
|
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? |
|
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. |
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. |
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? |
|
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). |
|
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: A few questions:
|
|
|
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 |
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. |
|
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). |
|
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. |
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
no, you should not export it anymore now :-)
|
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) |
|
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!! |
|
Kai, Feel free to merge then! Tim |
kaikreuzer
removed
the
awaiting feedback
|
Thanks again! |
* Initial Russound Implementation (openhab#1225) Signed-off-by: Tim Roberts <troberts@bigfoot.com>
* Update README (2.5.x) (openhab#1153) Change branch name. Signed-off-by: Yannick Schaus <github@schaus.net> * 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 <mrbig@sneaker.hu> * 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 <rwdrich@gmail.com> * 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 <jaco.waes@gmail.com> * Adding 12 new logos for OH Add-Ons page on website (openhab#1158) Signed-off-by: bracklanna bracklanna@users.noreply.github.com * Added missing preset variables (openhab#1104) * Added missing preset variables Signed-off-by: Scott Rushworth <openhab@5iver.com> * Cleaned up blank lines, fixed table, and added file name for SimpleRule Signed-off-by: Scott Rushworth <openhab@5iver.com> * 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 <github@christophweitkamp.de> * Incorporated changes from review Signed-off-by: Christoph Weitkamp <github@christophweitkamp.de> * Incorporated changes from review Signed-off-by: Christoph Weitkamp <github@christophweitkamp.de> * 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 <contact@wasv.me> * Changed all http links to https for installation/index.md. All changed links working, tested on 3/24/2020. Signed-off-by: Billy Stevens <contact@wasv.me> * Minor language tweak (openhab#1178) * Ending an active scan/stopScan (openhab#1179) Signed-off-by: Mark Theiding <mark.theiding@gmail.com> * Add files via upload (openhab#1184) * Update persistence.md (openhab#1185) Clarify return objects for max/min rules extensions. Signed-off-by: Ross Kennedy rossko@culzean.clara.co.uk * 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 <bjorn@helgaas.com> * 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 <bjorn@helgaas.com> * Correct typos and grammatical errors Correct some typos and grammatical errors. Signed-off-by: Bjorn Helgaas <bjorn@helgaas.com> * 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 opus42@gmx.de * Add image for insteon binding (openhab#1196) Signed-off-by: Rob Nielsen <rob.nielsen@yahoo.com> * typo (openhab#1198) Signed-off-by: Mark Theiding <mark.theiding@gmail.com> * 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 <mark.theiding@gmail.com> * 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 <rob.nielsen@yahoo.com> * 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 <cfergeau@redhat.com> * Added information about DateTime Group functions LATEST/EARLIEST (openhab#1206) Signed-off-by: Christoph Weitkamp <github@christophweitkamp.de> * 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 <mark.theiding@gmail.com> * 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 Schrott.Micha@web.de * 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 <github@luckenba.ch> Co-authored-by: Jerome Luckenbach <github@luckenba.ch> * 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 <github@maindrain.net> * 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 <mark.theiding@gmail.com> * [fmiweather] logo for FMI Weather binding (openhab#929) Signed-off-by: Sami Salonen <ssalonen@gmail.com> * 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 <mark.theiding@gmail.com> * 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 <mark.theiding@gmail.com> * Update contributing.md (openhab#1228) Small refinement on documentation change submission flow. Signed-off-by: Mark Theiding <mark.theiding@gmail.com> * Add doc folder to the binding directory structure (openhab#1230) Signed-off-by: Fabian Wolter <github@fabian-wolter.de> * 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 <zabkaste@informatik.hu-berlin.de> * 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 <github@fabian-wolter.de> * Update thing-xml.md (openhab#1236) Signed-off-by: Christoph Weitkamp <github@christophweitkamp.de> * Fix broken ESH links (openhab#1231) Signed-off-by: Wouter Born <github@maindrain.net> * 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 <git@fabian-wolter.de> * Update introduction.md (openhab#1239) * Update introduction.md Signed-off-by: Markus Storm markus.storm@gmx.net * 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 <github@luckenba.ch> Co-authored-by: Jerome Luckenbach <github@luckenba.ch> * 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 <github@maindrain.net> * Fix typo (openhab#1244) Signed-off-by: Wouter Born <github@maindrain.net> * 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 <sascha.billian@googlemail.com> * Use one line per sentence Signed-off-by: Sascha Billian <sascha.billian@googlemail.com> Co-authored-by: Jerome Luckenbach <github@luckenba.ch> * 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 mills@prettymachine.co.nz * 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 <olivierberaud@free.fr> * Fixed broken images. (openhab#1247) * Fixed broken images. Signed-off-by: Jerome Luckenbach <github@luckenba.ch> * Fix image path Signed-off-by: Jerome Luckenbach <github@luckenba.ch> * [documentation] clarification of representation property (openhab#1248) * [documentation] clarification of representation property Signed-off-by: Andrew Fiddian-Green <software@whitebear.ch> * [documentation] typo Signed-off-by: Andrew Fiddian-Green <software@whitebear.ch> * [documentation] adopt suggestions of reviewers Signed-off-by: Andrew Fiddian-Green <software@whitebear.ch> * [documentation] commas Signed-off-by: Andrew Fiddian-Green <software@whitebear.ch> * [documentation] typo Signed-off-by: Andrew Fiddian-Green <software@whitebear.ch> * [documentation] addopted suggestions of @bobadair Signed-off-by: Andrew Fiddian-Green <software@whitebear.ch> * [documentation] typo Signed-off-by: Andrew Fiddian-Green <software@whitebear.ch> * [documentaion] example added back Signed-off-by: Andrew Fiddian-Green <software@whitebear.ch> * [documentaion] simplified text Signed-off-by: Andrew Fiddian-Green <software@whitebear.ch> * [documentation] typo Signed-off-by: Andrew Fiddian-Green <software@whitebear.ch> * [documentation] adopted reviewer comment Signed-off-by: Andrew Fiddian-Green <software@whitebear.ch> * 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 <toweosp@gmail.com> * 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 <github@christophweitkamp.de> * Remove deprecated UIs, Eclipse Marketplace from sidebar Signed-off-by: Yannick Schaus <github@schaus.net> * Update branch name in README Signed-off-by: Yannick Schaus <github@schaus.net> Co-authored-by: Markus Storm <markus.storm@gmx.net> Co-authored-by: Nagy Attila Gábor <mrbig@sneaker.hu> Co-authored-by: Christoph Thiede <38782922+LinqLover@users.noreply.github.com> Co-authored-by: Richard Davies <rwdrich@gmail.com> Co-authored-by: jwaes <50528773+jwaes@users.noreply.github.com> Co-authored-by: bracklanna <16140600+bracklanna@users.noreply.github.com> Co-authored-by: Scott Rushworth <openhab@5iver.com> Co-authored-by: cpmeister <mistercpp2000@gmail.com> Co-authored-by: Ross Kennedy <rossko@culzean.clara.co.uk> Co-authored-by: Christoph Weitkamp <github@christophweitkamp.de> Co-authored-by: Skinah <32607303+Skinah@users.noreply.github.com> Co-authored-by: pali <pauli.anttila@gmail.com> Co-authored-by: ljsquare <laurens-jan@merkx-ewals.nl> Co-authored-by: PatrikG <40170469+PatrikG8@users.noreply.github.com> Co-authored-by: Elias H <E.Hackradt@web.de> Co-authored-by: Billy Stevens <contact@wasv.me> Co-authored-by: theiding <mark.theiding@gmail.com> Co-authored-by: jadcx <60408305+jadcx@users.noreply.github.com> Co-authored-by: Bjorn Helgaas <bjorn@helgaas.com> Co-authored-by: Jürgen Baginski <opus42@gmx.de> Co-authored-by: robnielsen <rob.nielsen@yahoo.com> Co-authored-by: GumbyMan82 <40233411+GumbyMan82@users.noreply.github.com> Co-authored-by: Christophe Fergeau <teuf@gnome.org> Co-authored-by: Paulo "JCranky" Siqueira <paulo.siqueira@gmail.com> Co-authored-by: Michael Rossner <Schrott.Micha@web.de> Co-authored-by: BugSmurF <52825547+bugsmurf@users.noreply.github.com> Co-authored-by: Jerome Luckenbach <github@luckenba.ch> Co-authored-by: josefscript <64727123+josefscript@users.noreply.github.com> Co-authored-by: Wouter Born <github@maindrain.net> Co-authored-by: Sami Salonen <ssalonen@gmail.com> Co-authored-by: Fabian Wolter <github@fabian-wolter.de> Co-authored-by: Stefan Zabka <zabkaste@informatik.hu-berlin.de> Co-authored-by: TRS-80 <25938297+TRSx80@users.noreply.github.com> Co-authored-by: sihui <10405486+sihui62@users.noreply.github.com> Co-authored-by: Andrew Mills <amil109@users.noreply.github.com> Co-authored-by: Olivier Béraud <olivbd@users.noreply.github.com> Co-authored-by: Andrew Fiddian-Green <software@whitebear.ch> Co-authored-by: LeeC77 <LeeC77@users.noreply.github.com> Co-authored-by: Thomas Weiler <18066810+toweosp@users.noreply.github.com> Co-authored-by: garretcook <garretcook@gmail.com> Co-authored-by: Michael Fielding <michael.fielding@gmail.com>
Implementation of new Russound binding (RIO)
Signed-off-by: Tim Roberts troberts@bigfoot.com (github: tmrobert8)