Thank you both for the quick reply. What if I’m using the companion app ?
In app configuration you can also clear the cache.
I will try to install Alarmo with a ‘virgin’ browser, see if i see the white screen as you do.
Caching issues are out of my control unfortunately…
1 Like
Thank you all again, it worked like a charm. That was an idiotic problem so my apologies for spending your time.
I see. Well that explains it. I’m not sure you can modify the device class for zwave sensors ? I will have to look it up. I might have to add a template sensor for each. Or I’ll just modify the source of your component to skip the class test, that’s probably the easiest way to solve this short term 
I’ll try a few things when I get home from work.
Yeah I understand. But it’s never a good idea to hard code these kind of restrictions, because it’s bound to fail at some point. People just have so many different and sometimes obscure configurations. Why not add a checkbox along the lines of “show all sensors” ? It would be unchecked by default.
You can do this via customize.
I also use Z-wave (OZW integration), in my case all motion / door sensors were automatically discovered with their correct device_class. Maybe your devices are not fully supported (yet)?
Its preferrable to have the device_class set correctly, so (when things are in place), you can could receive push notification’back door is open’, instead of ‘backdoor is on’.
Alarmo also applies some default settings for doors, motion sensors, windows etc. so perhaps it worth it to have them set correctly.
Correct. I use mostly Sensative strips, Aeotec Door sensor 7 and Fibaro motion sensors. As far as I remember, none of those were natively supported by the old OZW 1.4 integration. I had to manually add them to the xml. So the device classes were not set either. I never cared much, since I don’t use Lovelace other than for configuration.
Makes sense. When given device classes, everything works as expected. Thanks.
Oh and while testing I stumbled over this bug. I should probably post this on Github, but don’t have my login around. So I’ll dump it here I guess.
When a sensor that is not marked as immediate triggers, this error shows up:
2020-11-23 22:51:38 ERROR (MainThread) [homeassistant] Error doing job: Task exception was never retrieved
Traceback (most recent call last):
File "/home/hast/.homeassistant/custom_components/alarmo/sensors.py", line 182, in async_sensor_state_changed
if not res and sensor_config[ATTR_IMMEDIATE]:
UnboundLocalError: local variable 'res' referenced before assignment
I’m setting this up to communicte with my commercial alarm system via MQTT but don’t see where I can set the payload.
I need to be able to send subcommands and password for arming / disarming etc. Where can this be set?
Please check the documentation regarding the current MQTT implementation.
If you would like to customize payloads, I could add this.
from your earlier post I understood that you were OK with the default HA alarm state/command names, so these are currently in use.
Fixed it, thanks for reporting 
The docs don’t explain the passcode used or where this is to be entered.
I had previously linked to the interface I use to help explain the way the payloads are structured. It would be great if we can customise these.
In the docs I wrote that payload should be sent like this:
{command: "<my command>", code: "<my pin or password>"}
Your Paradox2Mqtt uses:
{
"password":"1234",
"Command":"arm",
"Subcommand":"0"
}
There are slight differences…
But I have to make a choice here. I guess every system defines their own structure.
How did you do this with BWalarm?
Was it directly compatible or did you change the payload structure?
Customizable MQTT payloads are on my to-do list as of now 
Yes, the docs explain what the payload looks like, but where do we enter the command or code?
In BWAlarm I entered the whole payload. Being able to do this would be the ideal solution to work for everyone
Hmm, I don’t really know what’s still unclear to you.
An example for a payload sent to the command topic would be:
{
command: "ARM_AWAY",
code: "1234"
}
Where “1234” is ofcourse a pin you have assigned to one of your users in Alarmo.
So the payload needs to be in JSON format, but that seems to be OK for your Paradox system.
Looking at the BWalarm MQTT implementation, the required payload format seems to be more like this:
ARM_AWAY {"code": "1234"}
Which is a bit of an exotic choice to be, and it seems incompatible with your Paradox MQTT gateway.
I will try to make it like this:
{
<choose your command argument>: "ARM_AWAY",
<choose your code argument>: "1234"
}
It would give you the option to make the structure compatible with what you use now.
My question is where does that get entered though? From my earlier screenshot it only has entries for the topics, not payloads. Which passcode is used for the mqtt payload?
In the ‘codes’ tab you can define users with their codes, and define if code should be pin or password type.
The same codes would be accepted in MQTT payloads.
But which passcode is sent on an outgoing mqtt message?
Alarmo only sends state updates, no codes. Don’t see the point of this either.
I suggest that you open a issue in Github if you want to discuss this further.
I don’t want to contaminate this thread 
Hi. Do this work with the alarm control panel Android app?
What do i need to change
I released v1.3.0 which allows you to configure the payloads.
This is added to v1.3.0.
There is a new option ‘Is override code’ in the users panel.
If you use this code when arming, the arming is forced and open sensors will be bypassed.
Needless to say this function is only useful when the alarm requires a code for arming.
I added this checkbox in v1.3.0.