Modules are added, I can arm and disarm them. Super!
I have few additional questions.
On/off fo rSyncModule/system will arm/disarm the system (for all cameras).
On/off for cameras will activate/deactivate the motion alert for this camera (in original Blink app the grey or blue person symbol).
You can create a flow with a trigger “motion alarm is activated” and react on (push info, lights on…).
Is there some way to synchronize the status of modules (on/off) with blink, if blink app was used to toggle them? For a moment I thought I could check if ifttt can do something, but for some reason I get no flows detected message.
The Homey app is polling the module state every 5min. So if you change the arm state in Blink app it should change in the next minutes in Homey.
Nice 
As I previously mentioned, I have 2 modules called inside and outside. The outside one is configured in the blink app to arm on schedule in the night, while inside does not arm in the night. Now looking at the homey device list, both modules are “on”, instead of just outside being “on”. Could it be a bug with polling the status of the modules from the blink API ?
No, all working fine here. Manual and automatic changes of modules will be visible in Homey within 5 minutes.
Still an issue with polling arming status of a module. My inside module is disarmed, but homey shows it as on. When I disable it in homey, it gets back to on afterwards.
So Blink is sending the state armed=true for this module. And changing to armed in Homey will not cause a change of the module state. Have you checked the state in Blink app (perhaps refresh the view), if it’s armed?
I habe only one module for test but this is sending the correct state.
I have done more testing on the synchronization and so far my conclusion is that it is a mess.
Option one: there is a delay of what data blink provides, so that the state coming to homey is delayed by a time longer than 5 minutes or it is behind by several changes of on/off states. Is it possible that you are reading a history of states, with the current one missing?
Option two: it is just random behavior if two modules are involved.
Few notes on my testing procedure.
Hardware:
Module 1 - inside - historically the first one added to the blink account
Module 2 - outside - subsequently added
Both modules disarmed in blink app.
Enabled outside module. Waited until sync. Result: Homey shows both modules enabled.
Disarmed both modules. Waited until sync. Result: Homey shows both modules disabled.
Armed inside module. Waited until sync. Result: Homey shows both modules disabled.
Disarmed both modules. Waited until sync. Result: Homey shows inside module enabled.
Enabled outside module. Waited until sync. Result: Homey shows both modules enabled.
Disarmed both modules. Waited until sync. Result: Homey shows both modules disabled.
Hi, thanks for checking these variants. Just wanted to ask you but you have been faster 
There is a simple but stupid mistake in the code which makes the filter for corresponding module not work. So every module in the list (read von Blink API) is recognized as correct for the current Homey device. So the state of the last SyncModule is take for all Homey modules.
I created a new pull request for @ObelixNL on Github with the fix.
It’s good you found the bug.
Looking at the code, there are references to either Indoor or Mini cameras. I also have outdoor XT and XT2 cameras. So far they were detected and listed in homey. I even managed to make a homey script function to collect temperature from them. But I have yet not tested deeper arming and disarming of the outdoor cameras, nor other aspects. Are they expected to just work using the part of the code for indoor? If they work, why not list them as supported devices in the homey app store?
That’s a question to @ObelixNL.
I only have the new Indoor and Outdoor camera. They both are the same, only one is designed for outdoor use. For the API there is no difference. So they can be added using the Indoor camera.
The device name can be changed to “Indoor/Outdoor camera”. Duplicating the code to get two devices is not so good.
I don’t know if XT is full compatible with Indoor/Outdoor. But if they are listed adding the “Indoor” devide, I would assume that. The Mini is only separated because it uses different API calls.
I don’t think it’s wise to have duplicate code, maybe it’s better to change the name to a generic name.
And check which functions support which camera to compensate for very small differences.
Well, here is what I have:
2x modules Gen 1 (white)
5x indoor cameras Gen 1 (white)
2x outdoor cameras XT (black)
3x outdoor cameras XT2 (black)
XT2 has different firmware from Indoor and XT.
All of the items are from before the money grab subscription model.
How can I tell which code path is used for my cameras - indoor or mini?
New test version is live! now its time for an ice cold beer and formule 1!
I’ a little bit jealous 
Depends on the device you select for adding the camera. If you select “Indoor” for your XTs and they are listed, then it’s the same API and they probably have the same functionality. So if something doesn’t word (like snapshot, activate movement alert) then please give us a hint.
OK, that’s what I did. I used Indoor model when adding all of my cameras. I should have remembered that
