I tried the MQTT and matched the passwords but just get:
Failed to open network connection: socket connection failed. Connection refused (os error 111)
But I just have no idea what I am doing as I don’t understand MQTT at all
You have to swap the wemos into mqtt mode (can’t do ST messages and mqtt at the same time), but it’s only a setting on the wemos, so if you want to get back to current behaviour it should be easy
I did turn on MQTT in the dashboard and set a username and password, I’m not sure how to do anything further, is the mode swap not done in the dashboard?
Hmmm in this case I would normally suggest a firmware update as I know the mqtt library used to have some bugs, and I’ve improved quite a few things in the hubitat version, but not sure if I’ve broken ST compatibility at some point. Maybe there is something in my release notes, based in your version
Thank you @cjcharles I know you are not developing this any more so I appreciate you taking the time to help.
It’s all a bit beyond my tinkering capability, so I just hope someone with a bit of skill can pick up on the tests we have been doing.
I also tried connecting with MQTT but the client I installed was unable to connect. Also ran a port scanner on the wemo IP and the only open ports were 23 and 80, not sure if that means anything or not.
I did enable MQTT in the wemo’s interface and also upgraded the firmware to the latest version…
I am not an expert on MQTT either, but just to make sure I understand, the MQTT interface is a pull interface? Should be able to query it by topic?
Where can I see what topics are published?
Did you reboot after changing to mqtt mode? Perhaps that was a required step, admittedly it’s a long time ago for me too. The topics will all be in this thread. The other option is getting a hubitat and then using the cloud connection to bridge devices to ST
This is certainly the most promising method.
I set up the three states in WebRequestor then set three routines:
When security app Arm(stay) pressed - set alarm to home
When security app Arm(away) pressed - set alarm to away
When security app Disarm pressed - set alarm to disarmed
It all works with the security app which was not possible with the old Groovy DTH.
The only thing is, it can be a bit slow sometimes to get a response from the alarm, that could be because I’m using the security app, I have not tried triggering the alarm with other devices.
@Arielgr any idea why the disarm does not work?
I can use either of the following to arm my alarm:
GET:http://192.168.1.XXX:80/armaway
GET:http://192.168.1.XXX:80/armhome
But when I use GET:http://192.168.1.XXX:80/disarm nothing happens?
I though the string was wrong so I checked the Dashboard and found that it will also not disarm my alarm (all the other links work)
Could the link be wrong in the dashboard?
@Anthony_S I think that’s the right link.
In the past I observed that if the wemo is not in sync with the powermax panel then only some of the commands work, others don’t.
What do you see when you click the status link? do you see a full output of all your zones and all the configured settings (pins, telephone numbers etc)? If not, it likely means they’re not in sync - unplug and plug the power and wait 15 seconds and check… normally that works after 2-3 times for me.
Alternatively check the Powermax Powerlink PIN is set correctly in the settings… I believe that’s necessary for everything to work correctly though the default 3622 normally works.
Otherwise… I have no clue 
This is the status output.
I will try powering down as I did a soft reboot trying the MQTT so that may have caused what you describe.
{“stat”:0,
“stat_str”:“Disarmed”,
“lastCom”:22,
“panelType”:1,
“panelTypeStr”:“PowerMax+”,
“panelModelType”:36,
“alarmState”:0,
“alarmStateStr”:“None”,
“alarmTrippedZones”:,
“flags”:32,
“flags_ready”:false,
“flags_alertInMemory”:false,
“flags_trouble”:false,
“flags_bypasOn”:false,
“flags_last10sec”:false,
“flags_zoneEvent”:true,
“flags_armDisarmEvent”:false,
“flags_alarmEvent”:false,
“enroled_zones”:}
@Arielgr
You were spot on, a simple reboot and all working.
I tell you what, I am very impressed with the WebRequestor driver, it works treat and having the alarm integrated into the Smartthings security app is the icing on the cake.
This is great news as I was able to use security monitor in the past as well as a routine to schedule the alarm.
How do I pull a status message if the alarm is activated ? Also, has anyone been able to pull the current status message from the json status page? I sometimes use the fob to disarm\arm the alarm and would like to keep the security status of the alarm in ST synced by reading the status message.
Would it at all be possible to pull the battery status for the various sensors as well? Thanks
I don’t think you can, ST will be able to arm as disarm through the security monitor or routine but it will be unaware if you have changed the alarms status using another method.
Is there nothing in ST now that can listen to HTTP/MQTT pings? The Wemos will send out notifications on every status change so its just a case of catching them through one of two methods!
Alternatively get Hubitat and use that as the bridge, since I believe all devices can be pushed from Hubitat into ST through a mirror/link connection. Then you can have complete control.
There’s an MQTT edge device creator which seems very advanced as you can create every type of device with it including an Alarm device and a motion sensor device…also had my first steps setting up mosquito (an MQTT broker - which is effectively the server that sits in the middle)… was able to see messages coming through from the wemos, which is a great first step…
Need more time to play with this, but it does look promising… other than needing to run mosquito on another machine…
Its almost like you need a Hubitat to run as MQTT broker or something 
So I’ve taken the plunge and setup a Mosquito MQTT broker on an old Raspberry pi.
Currently in pack of an edge driver, using TAustin’s MQTT device creator seems to get all the old functionality back (nearly*), including child devices for each of the sensors. The Alarm device created can be synced to ST’s Home monitor (STHM) by setting simple automations, so you get a nice well integrated interface within the app, and additional automation options.
In order to make this work, first get yourself a permanently installed mosquito broker (I actually tested the whole thing using a Broker App on my phone), then install @TAustin’s great MQTT device creator from this thread, get ST to create the device by running “add device”, and use it to create an Alarm panel and a device for each of your sensors.
For each of these devices you need to setup a topic to listen to
Panel (listen): alarm/panel
Panel (set): alarm/set
Zones: alarm/zone1, alarm/zone2 etc…
And, configure the topic values for each state of the device.
For example, here’s the interface of the panel:
And here’s the relevant settings:
Here’s a movement sensor:
And it’s settings:
The only thing that unfortunately doesn’t work out of the box is actually setting the alarm from the created panel. The device has the ability to both listen to a topic to change its state, and update a different topic to publish a state, but the values published for listen/publish are expected to be the same, and the wemo device is configured to publish “siren”, “strobe”, “off”, but listen to “AlarmArm”,“Disarm” etc.
@cjcharles I see in the past you were able to make some adaptations to the topic values… Any chance you still have this set up and could make the change so topics values match?
Any other suggestion?
Thanks for the information.
I keep a Windows Raid1 server on my system which would be perfect, but I don’t think I will be going down this rabbit hole, while I am comfortable(ish) using command line, I’m not investing the time and pain into this. WebRequestor using URL strings works perfectly well for my needs, I can live with it being a one way service, it does at least work.
Anyone considering this needs to know there is no GUI, so you need a good understanding how to set the MQTT broker up using command line.
Yes, you need a basic knowledge of command line… though really only a tiny bit as configuring the broker requires addition of 2 lines only.