Hi Florian
I missed that you created the documentation
Following it and also Thomas’s post above, I suceed to make it work
I tried to Arm and Disarm it and it works like a charm !
Excellent Job, really !
Thanks for your feedback, glad to know it’s working for you 
I’m going to fix the documentation right now 
Alarm panel is not yet updating, when arming physical alarm , I’m going to work in it… with same limitations about arming and disarming alarm 
Thank you very much for your thanks, I’m happy to know it work for you too.
Please note that for the moment, the alarm arbitrarily arms the ABC zones, I plan to give possibility to arm each zone independently (will required an alarm panel per zone)
@Thomas_Gregg, @isaste, what do you think about disabling alarm arming/dearming Hass.io switches entities, when activating alarm panel in Gateway configuration ?
This to avoid having possibility to arm/disarm alarm outside alarm panel.
Not sure if I understand correctly. But for us here HA is not used by the whole family yet and the keyfobs etc are especially used by the kids to arm / disarm the alarm system. So disabling this completely wouldn’t be something which works for us. But not sure if that’s what you were referring to.
I think that disabling “disarm” Haas.io Switch entities could be good for security purpose (means no possibiliy in HA to Disarm the Alarm without the code through Alarm Panel), but I think you should keep the the Arm Switch always available, to be able for example to Arm the Alarm by voice with Alexa.
Hi Florian
I think I found a small bug on binary_sensor.somfy_alarm_all state
I wanted to configure a nodered flow which close the Cover of my Desk when I arm the Alarm
Do do this, I test the State (True/False) of that Binary sensor ==> In fact it seems the states are reversed.
When I arm the alarm : binary_sensor.somfy_alarm_all = false
When I disarm the alarm : binary_sensor.somfy_alarm_all = true
I think the logic should be inversed, what do you think ?
Thanks
regards
Hi @Thomas, I was reffering to the possibility to disable arm/disarm switches in Hassio, in order to force Hassio users to use MQTT alarm panel (and not be able to arm/disarm with a single switch)
You’re right about letting arming possibility.
I’ll release soon a 0.6 version with possibility to :
- enable/disable switches (default : enabled)
- enable/disable disarm with switch (default : enabled)
Great I expect to relase 0.6 version today 
Hi @Thomas_Gregg and @isaste, 0.6 version is here 
Big update :
Zones can now be managed in MQTT Alarm Control Panel :
- all zones (ABC) armed
- zone A armed
- zone B armed
- zone C armed
Physical alarm arming/disarming, are dynamically reflected to MQTT Alarm Control Panel (zones : all, a, b, c)
Home Assistant switches for zones All, A, B or C, can now be enabled/disabled.
Existing Home Assistant binary sensors for zones All, A, B or C alarm armed status, can now be enabled/disabled (default : enabled)
Added Home Assistant binary sensors for zones All, A, B or C.
These new binary sensors can now be enabled/disabled (default : disabled)
Alarm disarming from Home Assistant switches for zones All, A, B or C, can now be enabled/disabled.
Created Home Assistant entities, are now set to :
- online, when add-on is started
- offline, when add-on is stopped
Created Hassio entities icons icons can now be customized.
Fixed configuration sample (@Thomas_Gregg)
Documentation is up to date, but don’t hesitate if something is not clear !
Sounds great. It seems the problem with sensors reporting unavailable after a hassio restart is back:
There is a workaround with manually restating both addons after hassio has started.
Thanks a lot for that update (which fix also the small buf I explained in above Post)
I’m not sure to understand the ne wfeature “Created Hassio entities icons icons can now be customized.”
Could you explain where we see those icons ?
Thanks
Hi @isaste, your welcome.
The icons I’m referring to, are the ones displayed in the Home Assistant user interface.
If you want to customize the defaults (and arbitrary 
) ones, you can do it in the configuration (it look like key/value pairs)
Fo example, on my Hassio installation, I’ve customized the door/window Somfy elements to reflect their types (door, window, garage_door), it now looks like this :
This is done adding “HassioEntitiesIcons” node and key value pairs. This works for :
- Somfy door/window elements code <=> binary sensor type
- Somfy global status or elements properties (like “box”, “alarm-triggered”, “gsm-communication”)
Here is what it look in my configuration (anonymized Somfy elements)
HassioEntitiesIcons:
- Key: 'alarm-triggered'
Value: problem
- Key: '298765'
Value: door
- Key: '298765'
Value: door
- Key: '298765'
Value: door
- Key: '298765'
Value: window
- Key: '298765'
Value: window
- Key: '298765'
Value: window
- Key: '298765'
Value: window
- Key: '298765'
Value: window
- Key: '298765'
Value: garage_door
- Key: '298765'
Value: garage_door
- Key: '298765'
Value: door
- Key: '298765'
Value: door
Thanks
Mhm, I still not undertsand why you have this issue when restart Hassio 
=> Does this occurs at each restart ?
=> If this occurs again, can you send me a MQTT Explorer capture in private message with details of a Somfy element entity?
You also had to physical restart your Raspberry when stopping and restarting my add-ons, does this still occurs ?
Do you need to restart both add-ons, or simply the Gateway add-on ?
=> The Gateway add-on should be suffisient because it is the one who create the entities with MTT messages publishes.
Please note that with 0.6 version, entities will now be marked as unaivable when you stop the “Gateway”.
=> Does this occurs at each restart ?
Yes
=> If this occurs again, can you send me a MQTT Explorer capture in private message with details of a Somfy element entity?
Done
=> The Gateway add-on should be suffisient because it is the one who create the entities with MTT messages publishes.
Just restarting the Gateway is not enough. It only works if I restart first the Proxy and then restart the Gateway. Maybe a timing issue while HassIO is booting?
Hi @Thomas_Gregg,
Thanks for your PM => online/offline MQTT message weren’t sent as retained ones (same than previous issue…) i’m gonna to fix it soon.
“Gateway” is supposed to wait for an operational “Proxy”, I’ll also check this problem this week
Hi,
0.7.0 version is available, all details are in the changelogs.
One important things @isaste and @Thomas_Gregg : Hassio devices’s battery levels only appears on my Hassio if I remove “battery” binary entities and only uses new “battery level” sensors entities.
Do you mind if I remove “battery” entities ? (who also have inverted logic… I should have named them “battery low”)
“Battery Level” entities are relying on the same alarm data but their values are 100 or 0 (battery OK / battery low)
Thanks
Hi Florian
Thanks for that update. A lot of work !
For the “Battery” entities, no problem for me. I didn’t use it yet
As discussed last time, in my nodeRed the status of the Alarm_all Arm/Disarmed was inversed, and after a new version that you released it was fixed, however, now it works but when I display the status of the Alarm on a Entiry Card in Lovelace, the state is wrong. It says “Locked” when the Alarm is Disable (look to screenshot below : AlarmPanel shows Alarm Disarmed (which is the case) but the Entity Cards is saying “Locked”
Again (actually in Nodered, if I check status of Alarm, it’s = 0 which is correct (see nodered screenshot below - I just trigger a read status and display it in the Debug windows on the right side)
As you can see, NodeRed State is correct, AlarmPanel is correct, but Entity value is wrong
