I noticed another abnormal behavior, as I mentioned in my previous post that soft reboot would reconnected with MQTT and HA but lately even soft reboot stopped working (means now if I do soft reboot if wouldn’t reconnect to MQTT or HA). The only solution I found if I go to http:XX.XX.XX.XX/advance (under Configuration Settings) and just hit ‘Submit Button’ without changing anything it will start working again. Hope this will help to figured out the cause.
I just updated ESP with your provided ESP Core 2.3 though. I will monitor and post any change(s). I also setup shell_command curl in HA to reboot PowerMax + everyday at 12:00 AM.
The submit button just causes a full reset of the MQTT connection, sadly not too helpful. I’m sure the old ESP core will fix things for you and no need for the reboot. Will also test out the newest version as soon as they release it, given it does seem to contain a few good improvements.
I had few power cuts recently and I have noticed the same issue; I have to resubmit my MQTT configuration settings, it could be a problem if I don’t have access to the Wemos web page when I am away.
Is this with the 2.3 core?
No I don’t think I am running the current codebase compiled on old ESP core 2.3, I probably use the latest build you published (is there an easy way to check?).
If you let me know the compilation time (in the settings of the Wemos dashboard) you should be able to work it out. If using MQTT it seems you need to use the 2.3 core firmware which is linked a few posts above, anything else has proven unreliable.
That fixes my issue, no problem with MQTT after restarting my Powermax and my router. Thanks!
After following your suggestion I flashed WEMOs with Core 2.3, its been more than a week now and so far no issues with MQTT or HA, and I didn’t even have to reboot WEMOs. Thank for your help brother.
1 Like
Hi @cjcharles - thanks for all your work. I bought the full kit and everything is ‘mostly’ working.
I have full connectivity, can arm/disarm and see the (one zone) I have.
The ST App is configured and again, I can arm/disarm.
But the sensor response seems to be flaky - there is a delay reporting motion detection, and for the last hour or so, the App has been reporting the sensor as motion, when there is none.
I noticed in the live logging this error:
8:59:00 PM: error java.lang.NullPointerException: Cannot invoke method toJson() on null object @line 63 (initialize)
8:59:00 PM: debug device untracked
I removed the child and added again with no luck.
I havent added the Arduino as everything seemed ok - do you think worth having a go?
Also, suggestion: is it possible to get Alexa integration working? E.g arm/disarm ?
Can I suggest restarting your ST hub. Sometimes ST can get a bit sticky (no idea why), but a restart always sees to fix it. Im not convinced that error message is from this device since that code is not used in this device handler at all, next time you see the error can you filter for the Visonic device in Live Logging to confirm what device is causing the error. Sometimes it also just needs time to settle over a day or a few hours, especially if you have created lots of children and removed them, it is likely to do with the amount of CPU time to process all updates.
As for using Alexa, then this device handler is easy to link to virtual devices through WebCore, and you can call all of the alarm control methods from WebCore. However, I would not recommend allowing disarm, only arm, since otherwise I feel you defeat the benefits of having an alarm!
ok some more info - I rebooted ST and I now get a more consistent detection.
However, on the child devices, something odd is happening.
The java error was defintely for the sensor device (PIR). I had it filtered already. I tried moving it into a zone lower than 8, in case it was because I had added it to 11 (having modded the DH).
But the error still appears (once), even though the child device seems to operate correctly.
However, the child device Live logging doesnt report any status changes beyond that error.
Nor does live logging report child status for another sensor (e.g magnet) that doesnt generate the error - should it?
And finally, apologies if you know this already, when I delete a zone from the hardware panel, the corresponding tile in the App doesnt get removed or cleared.
I expect it could well be caused by moving around zone names then. The Wemos only pairs with the Powermax/Powermaster on bootup, and hopefully never needs to repeat the process until the next reboot. This is the point when device list is updated, so you might also need to reboot the Wemos to see all zones correctly appearing (clicking on the /getzonenames link on the Wemos webpage will show you if it has everything correct), and then its just a fiddle getting ST to tally (but only needs doing once).
Live logging shouldnt really show much for the zones as I tried to keep it clear of unnecessary information but if the above doesnt fix things, then perhaps I can add some temporary debugging to investigate further.
Thanks - I went through the reboot of Wemos process and can confirm the zones are correctly pulled. But deleted ones one the panel are not reflected in the tiles.
On the child device java error, I can recreate it every time by using the ST App and Visonic Alarm Remove Zone devices, followed by Create Zone devices. It only happens that one time and seems irrespective of the number of zones.
Look, they’re both cosmetic and everything seems to be working so no need to spend effort on the java error.
Once a zone ID name has been set in ST there is nothing to reset it apart from completely removing the device and device handler to reset the integration (sometimes the IDE allows you to reset custom DTH variables but I havent worked out when). However you can safely hide the old device ID tile so you dont see it on the panel (and it shouldnt create children for inactive zones, or try to update them).
Can you send me the output of your getzonenames - perhaps you have a funky sensor type that I havent recorded, and that is causing something to get confused when creating child devices.
Hello @cjcharles, Thank you so much for the excellent writeup and the details. Is there any help you can provide with following setup?
-
I have a Node MCU ESP8266 CH340G was able to flash esp-link.
-
Connected Visonic PowerMax Pro (USA version) with TX/RX/G/3.3v pins.
-
I could get to esp-link portal (http://192.168.0.111:23 ) and the uC console showing following output with baud 9600 when I arm/disarm my alarm system. I also tried with different baud settings.
xxxxxxxxxxxxxxxxxxxxuxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxaxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxx
I am lost at this point on how to integrated SmartThings hub. I followed entire thread couldn’t get much informatino since I am using NodeMCU.
I also tried flashing your binary, but couldn’t get the Wifi access point ‘VisonicPowermax…’ after the reboot.
I really appreciate any inputs.
Thanks,
Supa
I suspect you are getting a lot of 0x80 and 0x88 messages, that some old panels send out, especially when the voltage levels are out of sync. There are a few points to note:
- ESP-link does not work with Smartthings since ST is not smart enough to decode all the messages
- Powermax does not have a 3.3V pin, it has a 3.75V pin
- NodeMCUs give significantly worse performance than a Wemos since they have to run at 3.75V which can give extra noise to the serial comms and can give extra voltage rail noise for the Powermax (which actually damages the NodeMCU and Powermax over the course of months/years - seems to vary based on how noisy the Powermax voltage levels are). Meanwhile the NodeMCU requires 3.3V.
- Its hard to know what those output messages are since you would need to do some serial debugging using esp-link to delve into the messages properly. The Arduino that I have created was designed to fix this, so perhaps that would help solve your problems.
- If you didnt get the VisonicPowermax AP after flashing, perhaps try skipping that step, you might have left the WiFi details saved on the device and hence it wouldnt need to broadcast its own AP
Hi @cjcharles ,
I’ve been playing around with Hubitat and saw you had a Device Handler (Drivers Code) on your github.
I loaded this and got the PowerMax panel working for arm and disarm.
It also creates the child devices also but I don’t get any status changes from the child devices.
Played around using different device handlers for the child devices and also imported some smartthings device handlers to try with but no luck.
Did you ever get this working at all?
Cheers,
Stuart
As an update:
When I trigger an open/closed sensor by opening a door, I get this in the Hubitat Log.
I’ve taken out the actual IP’s and MAC address.
sys:12020-05-29 07:48:34.849 pm warnReceived data from WemosIP, no matching device found for WemosIP, AC1064C6:C0FC, WemosMAC or AC1064C6.
As a random test, i tried putting the Wemos MAC as the PowerMax Device Network ID.
The error changed to:
[dev:295](http://Hubitat IP/logs#dev295)2020-05-29 07:54:05.695 pm errorjava.lang.ArrayIndexOutOfBoundsException: 1 on line 669 (parse)
Dont know if this helps in any way! 
That is strange… I’ve never done much testing with hubitat as I’ve never owned one myself. Has line 669 moved in your device handler after tweaking zone names? Since with the default line 669 (as on GitHub) I can’t make much sense of what would trigger that error.
Happy to jump on a screen share and do some debugging if you want, as I do think it would be useful to support hubitat. Drop me an email and can maybe work something out.
Hi @cjcharles
I bought the wemos from your store and it’s been working great with the smart things app. I do get push notifications but no audible alerts. Is it all all possible to add:
- Chime on the powermax panel when e.g. the front door is opened
- Get an audible alert on the smartphone. I don’t seem to be able to figure out how to get this integration working even using the SHM app.
Thanks
There is no control of chime possible through the Powermax serial interface, either individual chime or changing the panels chime settings. However that doesn’t stop you entering the chime settings on the panel directly when one of its sensors changes (totally outside of this integration).
As for sending a push message to your phone when a sensor changes then look at webcore. I have mine setup to do the arming and disarming based on rules (e.g. location of certain phones), whilst also sending notifications when the door opens or doorbell rings.