I have published a new test version with a different approach to detect multiple Tahoma’s in one account.
At eh very least it has some extra logging to try and see what is coming back, so if it still doesn’t work then send the new Information log. Also, make sure the Log is enabled and then restart the app Give it a minute and then send the log again.
Log id 1636663.
the log appears empty.. followed procedure twice
EDIT
Sorry not empty, mobie app shows the log as one line..
The log looks promising as it shows multiple OID’s, so now just to work out how to get the devices from each one.
I have published a new test version that tries to split device fetching a bit more to see if that helps.
log-ID: 161036663
Installed the latest (145) and reset app, log sent.
No result change in driver info (only NL devices detected)
No result change adding devices (only NL devices show up)
Ok, so it is still a mystery how to fetch the devices from the second gateway.
I will keep digging.
Ok, I’ll be on standby. Note that I have to do things remotely, so reset tahoma etc is not possible.
Thanks!!
What if you implement IP addressing, so 4get the mDNS and search for nodes ip based (wan or preferably lan)
The app has to use the local url for the SSL certificate to work. The latest version of the app does does provide a local DNS lookup based on the mDNS report.
Ok! But it should not make any difference for the certificate to use ip entries (by user settings) instead. If the ip does not match for any reason, the certification fails and error is generated.
I’m not sure I understand what you are saying there.
What IP address do you want to use?
Many apps use the input of local ip address to comm. With a device. Why rely on mDNS? if the user is able to enter 2 or more lical ip adresses, you might benefit from that. We discovered only onr local ip address is in the log, and thats pure mDNS. Hope this clarifies what I mean but your expertise is more important than a suggestion I think 
The local TaHoma API uses HTTPS with certificate validation, so the connection is not just “can I reach the box on this IP”. The TLS handshake also needs the host name to match what the device certificate expects.
In practice that means the app cannot safely switch to using only the raw IP address for the HTTPS URL. It needs to connect using the TaHoma local host name, such as the .local name, and then resolve that host name to the current IP address underneath.
So even if the IP is known and reachable, using only https://<ip>:8443/... is not equivalent to using the device’s local host name. The IP may route the traffic correctly, but certificate validation can still fail because the certificate identity is host-name based, not IP-based.
That is why the app uses the local URL/host name for SSL, while separately tracking the IP address for discovery and resolution.
Because the Athom App guidelines state to only ask a user to enter an IP address when there are no other methods of detecting it. Also, IPs can change via DHCP, but hostnames can’t.
This is the reason that f.e. my Asustor app uses EZConnect Cloud service to discover the IP address of a NAS instead of manual IP entry: if the IP ever changes, it can be picked up without manual action required
Thanks for taking time to explain, I get the picture.
The fixed IP address by mac is commonly used to prevent some issues but I see the ‘advantages’.
Although in this case it’s not just an advantage, it a necessity.
Also, Homey can only reach a Tahoma that is on the same network using the ‘local’ connection. For the remote Tahoma, the cloud connection is the only option apart from a very well configured VPN.
Well, let’s hope for the best. Standby for any try-outs, log sends etc. 
From you last last log, I can now confirm the app is querying both setup IDs correctly, including setup-scoped endpoints for your second setup. However, Somfy currently returns the same device list for both setup IDs on your account session, so no additional devices can be added by the app. In other words, the app is not missing the second setup; the API response is duplicated across both setup scopes for this account context.
I presume you are the owner on both Tahoma’s and not a guest on one?
What devices are missing from Homey?
The app is finding 18 devices, but 9 of them will be unsupported internal devices, so does 9 device sound correct for one location?
I have run out of ideas now, so I’m not sure this will be possible given the limited access to information from Somfy.
Ok, the situ is as follows:
I support my neighbour setting up a large house with well over 150 Hue devices, 5 airconditioners, Sound systems in all rooms, automated ventilation, automated watering system and OX pool unit, inverters, batteries and much much more. Been setting this up for well over a year. The house build is completed and somfy facts are the ‘closing-deal’. The NL Tahoma is operating 2 years now, the wish is to add all somfy devices in ES as well.
So not the owner, but access (remotely) to everything (with consent) Let me check on the devices and report back precisely.
EDIT, I need some time, later this evening or tomorrow. Sorry for the delay.
Hello. First of all thanks a lot for creating this beautiful app. I have a lot of Somfy stuff like blinds and shades and it all works perfectly.
Now we recently installed a new garage rolldoor and it has a Rollixo io system. It is connected with Keygo io remote controllers which basically act like pulse inputs. When the door is closed: first tap it starts opening, second tap it stops in current position, third tap it closes, fourth tap it opens, etc. I connected the door with Tahoma and then via Homey as ‘garage door (open and close) io’. I can open it and close it now with Homey and it works perfectly. So far so good.
When using the door in flows, I also noticed that besides the states ‘open’ and ‘close’ in Homey, I can also select state / status called ‘stil’ (not sure about English translation). However the state ‘stil’ does nothing. The door does not react to it and just keeps opening or closing whatever it was doing. I also tried to use the MY state, and that one does actually does work, however it does give me a error message ‘Request failed with status code 400’ while executing the card. It does continue with the flow even though it gives me a error message. In the Tahoma app I can also open and close the door. When opening or closing in the app a black dot appears in the middle where I can stop the action from continuing. I guess this is why the MY position in Homey does something.
Flow is attached as picture.
I wanted to use the flow for having the mailman deliver packages into the garage door. As most packages are small, I could first chat with the guy through my doorbell and then manually execute the flow ‘Package’ whereas it opens the door, stops after 5 seconds when the door is only 1/3 open for 120 seconds or so and then closes again. It works, but I don’t really feel comfortable executing a flow that displays a error message everytime. Also it seems to cause crashes more often to my Tahoma app because the garagedoor does not update the status all the time in the Tahoma app and when opening the app I often get connection errors. If I click refresh in the app it seems to reconnect all my Somfy stuff is visible again, but still something seems off here.
Is this something that is supposed to work this way? Could I do this different somehow and if not, would it be ok to still run this flow even though it displays a error message everytime?
Thanks for the assistance!
