securitySystem capability Arm fail using STSDK but disarm works and other odd issues

I receive the popup “A network or server error occured. Try again later.” When I try and Arm Stay or Away using the securitySystem capability with a direct connected ST device.
codebase: https://github.com/nutechsoftware/AlarmDecoder-STSDK

I see no message on the IoT device from the cloud in response to Arming.

I captured this from my phones log.

09-17 14:37:46.485 24316 24452 E [-8]oneconnect[1.7.51.42_01][PLUGIN_WEB_APPLICATION]: CommonJsInterfaceImplExtension.scpluginProdAnalyticsLogInsert - Exception: - org.json.JSONException: Value armedStay at value of type java.lang.String cannot be converted to long

I am still trying to determine if this is something I missed when initializing the capabilities on the IoT device. I am not able to find much/any docs on the capability.

Any help is appreciated.

Hay @erickv

Any thoughts on this issue. It is reproducible and AFAIK it is not an issue in my code on the Embedded side. The problem seems to be in the cloud. I also have other questions that I can’t to find answers for so hopefully I can get others to chime in :slight_smile:

I am sure many of my questions are well documented but as of now I have not been able to find any details on these specific questions.

Thanks for any and all support of my project it is much appreciated.

  • healthCheck does not seem to send PING. How do you kick off health checking and set how often a PING is sent?
  • How can the user send an ARG. Can I build a dropdown the user can select from that is sent to the Embedded device so it can in effect be “configured”.
  • Does any form of “Confirm” momentary button exist. A Panic button that wont be too easy to trip on accident.
  • I need to show N(max 10) number of Zones states to the end user. 1. How do I dynamically create capabilities inside of a Component. 2) Can I create an Array of capabilities inside of a component. I can’t figure out how to have 10 contact capabilities inside of one Component. Having 10 Components for a simple list of ON/OFF states seems difficult for the end users.
  • Can I create folders? A way or organize components?

@mathewss Did you find any solution to this?

Sorry nothing new. If I do find anything I will report back to this thread. Please do the same. I am watching this thread closely.

I mentioned a few specific areas so up vote specific features I mentioned or new ones that are in the same vein. My biggest issue is again some form of MULTI button.

A new one to add to my list.
On the “Add automation” screen when you select a device it shows no info on the device name making the interface very difficult to use. This falls under the category of not being able to update static text of common components over the MQTT protocol.

I think the armStay and armAway doesn’t work because they require an argument (bypassAll) while disarm works because it doesn’t require any arguments. Still this needs to be fixed as securitySystem is live capability and it should be working.

1 Like

I ended up removing it from my project and just used a momentary for each arm / disarm option. Also this needs more than just stay and away. MAX, NIGHT, INSTANT are common alarm states that should be added or we need a way to add custom ones.

I tried replicating the systemSecurity capability into custom one, that didn’t work either and the disarm command stops work in custom capability as well, seems everything is broken or half baked at this point in time.

I encountered this issue a few months back. The obvious connection between the securitySystem capability and the STHM status makes me wonder if there is actually a clash.

Certainly in legacy device handlers the attribute namespace is shared and flat so attribute names have to be unique. The ‘SHM status’, which in capability terms is the alarmSystemStatus attribute of the alarmSystem capability, was an attribute of the location, and it would make sense if the ‘STHM status’ is implemented in a similar fashion, albeit somewhat more securely.

Or it might just be a cock up. It certainly almost works.

Hi,

Same problem here in september 2021. The ArmStay and ArmAway security mode produce a network error in the app and nothing is called in the device handler. Disarm is working. I’m only using the capability “Security System” and tried the no parameter function signature and with the bypassAll argument.

Any ideas on this since 2020?

Thank you!

Simon

No. I came to the conclusion that the app simply didn’t support the capability as a general device capability, instead only supporting it on the location as the ‘Security Mode’. That it itself has some potential, but unfortunately it seems the ‘Security Mode’ is being treated as the exclusive plaything of STHM. I say that because when I fell asleep with my phone on my stomach and somewhat improbably deleted STHM (yes really, and webCoRE too) all my Automations involving the Security Mode were automatically deleted.

That is something of a contrast with the old Alarm System capability, the SHM status of old. When SHM was deleted as part of the app migration, it remained possible to access and control the Alarm System via webCoRE and ActionTiles just as it always had been. The fact that SHM was no longer there was completely irrelevant. That really should be the case with the Security System too.

Ho, I see. Thank you for pointing us in the direction of the Home Monitor probable cause!

It mean that there is no longer built-in capability to handle a LAN device that act like a security system and that with the recent developments of the platform, we should completely rewrite it with custom capability (CLI, Edge, LUA Driver, …) !? If it so, it’s not the same workload and the effort is considerable if you compare to the old style DTH and Groovy. You know, the good old style Tiles in the legacy App!

It really needs the input of someone who knows how things are intended to work.

The old Alarm System has always looked out of place in the capability list. I was surprised when I first accessed capabilities in the API and that appeared. It is at best non-standard and clearly not something that can be applied to a device as it has Location events instead of commands.

The Security System, however, looks like a ‘normal’ capability, albeit one with an undefined bypassAll argument in a couple of the commands. Perhaps it is intended to only be used for the Security Mode but it sure doesn’t look like it and if it is then that needs to be documented so we don’t waste our time on it.

I never did try accessing the Security System capability with the Rules API rather than Automations, just to see what it did when kept out of the clutches of the app developers.

Effective as they were, I always thought the Tiles in the DTH were a particularly ridiculous concept. None of that metadata section really belonged inside the device driver, but defining the UI for a client app in there was especially odd.

It really needs the input of someone who knows how things are intended to work.

If we could have an input from the good staff member at Smartthings, or if someone in the team would like to give us some infos on this, that would be perfect. Unfortunately, although I’m sure someone out there knows the answer, it doesn’t sound like anyone cares!

Effective as they were, I always thought the Tiles in the DTH were a particularly ridiculous concept. None of that metadata section really belonged inside the device driver, but defining the UI for a client app in there was especially odd.

Not the best practice to define the UI of the device in a driver, I agree, but simple to implement as a basic device user interface, if you compare to the new design that implies to redesign de whole thing. After that, if we wanted a more powerful interface to use the device, the SmartApps do the work.

1 Like