@patrik_gfeller if you want to allow others to update the article, you have the option to transform the article into a wiki article. Please do not feel pushed to do so but perhaps you think it’s a good idea.
Would like to do that - but I do not know how 
- any hints?
Below the posting next to the edit pen icon press the three dots, then the wrench, then select “Make Wiki”
It seems as I do not have enought rights; as I can not see this option:
I see, I did not know that 
… can you wikify it for me 
Already done 
1 Like
Would be nice to have a binding to make this more accesible for users; unfortunately I´m not familiar with maven, GIT nor the OH infrastructure - but could maybe help to implement some classes.
If someone has interest would be a nice addition in my opinion.
with kind regards,
Patrik
2 Likes
I’m also not the right person to ask for this but maybe you could post this idea to the first posting and someone takes up the task. @kubawolanin or @dolic / @opus developed similar bindings recently…
1 Like
I´ve started to setup the OH2 IDE to get an idea how complex a binding development would be. I created a new empty binding using the script. I can start the runtime; but can not see my stub (nor any other) binding in paperUI:
Any advice is appreciated 
with kind regards,
Patrik
You need to select your binding in the setup of the run or debug-configuration to be loaded . The bindings you see selectable on PaperUI have bogus names.
Hello Jürgen,
thanks … I do have see the dummy binding now
with kind regards,
Patrik
@patrik_gfeller Thanks for giving it a start.
Please don’t forget to open an issue on github for this, so others will know that a binding is under development and discussion about coding related topics/issues can be moved there.
As I was also hinking of stepping in, but stepping back cause of not much time atm, I would like to share my thoughts about how such a binding could look like.
I was thinking of having one bridge thing for each apple account, with appleId, passwort and refresh cycle as configuration options.
The first retrieved data could then be scanned for the devices and things could be created dynamically, identified by uuid and their names.
I would also see channels be created dynamically, according to the retreived data, so it could be taken into account, that not all devices have location data.
Wdyt?
1 Like
Thanks for your inputs … I´ll give it a try to see if I manage to create something that works; but any help is appreciated - as I´m new to almost every aspect involved (git, java osgi …) . Created the issue as sugested:
2 Likes
… basic bridge communication and parsing works; now I´ve to figure out the discovery mechanics to add the devices and how to keep them updated - but I´ve fun:
Data is already parsed:
2 Likes
Great stuff!
For device discovery, you can have a look at HUE or WeMo binding (WeMo link), both do a device scan after the bridge is discovered.
I would be happy to help. You can push your actual work to your fork. I, or others can then have a look there.
Great,
You are missing to register your deviceDiscovery in handlerFactory, like you can see in WeMo binding e.g.
if (thingTypeUID.equals(WemoBindingConstants.THING_TYPE_BRIDGE)) {
logger.debug("Creating a WemoBridgeHandler for thing '{}' with UDN '{}'", thing.getUID(),
thing.getConfiguration().get(UDN));
WemoBridgeHandler handler = new WemoBridgeHandler((Bridge) thing);
registerDeviceDiscoveryService(handler);
return handler;
This is just a quick response, I will have a closer look this evening…
To not flood this post with development stuff, i will post my further comments in the github issue.
2 Likes
@hmerk
Hello Hans,
fortunately I was able to figure out most of the stuff; discovery, parsing & thing handling works in the prototype. But I´ve no idea how far I´m from best practices (e.g. if such code has a chance ever to see the OH2 repo). Thus I would appreciate some feedback prior to going to the work of declaring all the channels.
with kind regards,
Patrik
1 Like