Driver max length of parameters: text | json_object

Hello Guys,

I am developing a custom driver that dynamically creates virtual devices based on a topology JSON parameter, during my tests everything was working as expected, but now that I need to add the full json (string) and its giving me a 500 error page.

I have tested with both text and json_object types but it's the same:

Update: Device driver input field:

Working Example Driver:

import groovy.json.JsonSlurper
metadata {
  definition (name: "test", namespace: "blabla", author: "blabla") {
    capability "Actuator"
    capability "Configuration"
  }
  preferences {
    section {
      input name: "vd_data", title: "json string", type: "text", defaultValue: "", required: true
    }
  }
}
def configure() {
  def slurper = new JsonSlurper()
  if(vd_data != null) vd_data = slurper.parseText(vd_data)
  log.info "${vd_data}"
}

My testing (working) json is about 175 chars and my full json version (Not working) is about 600 chars parameter.

Example parameter payload:

json string that generated the error at submission

{"Shade:SalonBack":{"close":"AA B0 35 05 08 12C0 05FA 02B2 017C 2343 481A3A3A3B2B2A3B2B2B2B2A3A3B2B2B2534536457B2B2B2B2B2A3B2B2A3A3B2B2A3A 55","open":"AA B0 35 05 08 353 0604 02B2 0186 226A 481A3A3A3B2B2A3B2B2B2B2A3A3B23465362A3A3B2B2B2B2B2B2B2B2B2A3B2B2B2A3B2B2B2A 55","stop":"AA B0 35 05 08 3435 35 02B2 0186 227E 481A3A3A3B2B2A3B223552453452B2A3A3B2B2B2B2B2B2B2B2B2A3B2A3B2A3B2A3B2A 55","cycle_time":100},"Shade:BedroomMain":{"close":"AA B0 39 07 08 060E 029E 017C 010E 000 1E8C E092A1A1A3463562B192B192B1B1B192B1B1B1B191B1B1B191C1B19292B1B19295 55","open":"AA B0 39 07 08 060E 0343 019A 0122 00B4 0008 E092B1B1A13463192B191C1B1C191C1B1C1C192B1B1B192B1B1B192B1B1B195 55","stop":"AA B0 37 06 08 0622 028A 01A4 010E 00B4 000 D092B1B1B1B1B192B1B1B1B1B1B156858578B191B1B1B192B192B192B192B192 55","cycle_time":100}}

Is there currently any kind of limitation? is yes any way of working around this?

Thanks in advance,
Seb

By way of an FYI
I have a weather driver that queries Weather Underground
This returns a json reply which contains much more than 600 characters and puts it into a single variable.
So I don’t think the error is related to the size of the json.
More likely is that the json is not formatted correctly.
There are a few json testers available on the web which you can use to check the json

Andy

Thanks for the reply but I think I did not explain my self correctly, sorry for that.

The problem is not on Groovy side, but on the form or web api the submits the driver parameters, this is were I think there is some kind of limitation:

Shouldn't your map have double quotes around each key and value? This would generate your first key as "Shade:SalonBack" I would think you'd want it to be "Shade":"SalonBack". But if you do that, this will no longer be a valid JSON because you need a key for the close and mac address. If you want to include multiple values for one key, you have to wrap that in brackets, don't you?

I think in general, you're not following the format of a JSON object. It looks like all you have are values with no keys. That isn't going to work, is it? I think you need to format it more like the json you get back from the Maker API.

Summary

{"id":"4075","name":"Hampton Bay Fan Component","label":"Office Fan","attributes":[{"name":"level","currentValue":25,"dataType":"NUMBER"},{"name":"speed","currentValue":"off","dataType":"ENUM","values":["low","medium-low","medium","medium-high","high","on","off","auto"]},{"name":"switch","currentValue":"off","dataType":"ENUM","values":["on","off"]}],"capabilities":["Switch",{"attributes":[{"name":"switch","dataType":null}]},"SwitchLevel",{"attributes":[{"name":"level","dataType":null}]},"Refresh","Actuator","FanControl",{"attributes":[{"name":"speed","dataType":null}]}],"commands":["cycleSpeed","off","on","refresh","setLevel","setSpeed"]}

2 Likes

@Ryan780, I am actually using a string that contains json that I then convert back to an actual json object, sorry for the miss leading screen shot.

Code snip it of what I am doing:

import groovy.json.JsonSlurper
metadata {
  definition (name: "test", namespace: "blabla", author: "blabla") {
    capability "Actuator"
    capability "Configuration"
  }
  preferences {
    section {
      input name: "vd_data", title: "Groovy Map", type: "text", defaultValue: "", required: true
    }
  }
}

def configure() {
  def slurper = new JsonSlurper()
  if(vd_data != null) vd_data = slurper.parseText(vd_data)
  // usage of the json object vd_data ...
}
Sample json string that generates the error

{"Shade:SalonBack":{"close":"AA B0 35 05 08 12C0 05FA 02B2 017C 2343 481A3A3A3B2B2A3B2B2B2B2A3A3B2B2B2534536457B2B2B2B2B2A3B2B2A3A3B2B2A3A 55","open":"AA B0 35 05 08 353 0604 02B2 0186 226A 481A3A3A3B2B2A3B2B2B2B2A3A3B23465362A3A3B2B2B2B2B2B2B2B2B2A3B2B2B2A3B2B2B2A 55","stop":"AA B0 35 05 08 3435 35 02B2 0186 227E 481A3A3A3B2B2A3B223552453452B2A3A3B2B2B2B2B2B2B2B2B2A3B2A3B2A3B2A3B2A 55","cycle_time":100},"Shade:BedroomMain":{"close":"AA B0 39 07 08 060E 029E 017C 010E 000 1E8C E092A1A1A3463562B192B192B1B1B192B1B1B1B191B1B1B191C1B19292B1B19295 55","open":"AA B0 39 07 08 060E 0343 019A 0122 00B4 0008 E092B1B1A13463192B191C1B1C191C1B1C1C192B1B1B192B1B1B192B1B1B195 55","stop":"AA B0 37 06 08 0622 028A 01A4 010E 00B4 000 D092B1B1B1B1B192B1B1B1B1B1B156858578B191B1B1B192B192B192B192B192 55","cycle_time":100}}

But this is still not going to parse into a JSON object. But why are you taking a string to a JSON just to parse it back out? I'm not understanding what you're trying to accomplish here.

I don't understand why you say it does not convert the string json into an json object? It's working on my side with small json strings.

Actually I need this to dynamically create virtual devices from the provided user parameter (json string), currently there is no way of automatically discovering the devices.

I just updated to 2.1.8 and I am still seeing the issue, this must be some kind of hard coded limit.. :frowning:

@mike.maxwell Sorry man for poking you directly, but I think only you guys will are the only ones that can really know if this is a limitation or bug..

Thanks in advance

Never mind....i see it in the wrap up details.

Can I ask something....where is the user going to get such a file to put into the driver?

I think you're running into a character limit for driver settings...has nothing to do with JSON.

In the original post, I added the example json string "json string that generated the error at submission" and also added an example driver were the you can test the isseu

I did some quick testing with only alphanumeric characters. It appears the error occurs at 256 chars, so it appears the field limit is 255.

Since apps do not appear to have this limit, the best approach to this is to create a service manager app that handles the connection process including the entry of those strings and virtual device creation. Your strings can then be passed and stored in each virtual devices state object which can store larger quantities of data.

1 Like

@srwhite, Thanks for confirming this hard coded limitation, for the moment I will just include this string as par of the driver, as adding another app to manage this would be just over kill.

Hope one day you guys can increase this limit.

1 Like

Why? This is the first time I've ever seen someone run into that limit. Increasing that limit would mean a change to the entire device database.

I have to agree. This is one of those cases where you probably want to sit back and re-think what your end goal is. You mentioned creating a service manager app is "way overkill", but I am curious as to why?

A service manager app is able to remove the burden and overhead of the connection process from the driver itself, keeping the driver lean and mean, able to execute without placing too much load on the hub.

1 Like

Especially since the OP said that this JSON is only needed for device creation. So, one time only.

1 Like

Thanks all the for feedback!
For the moment as its just a one time operation, I have included it in the driver this way I ave less dependencies on the installation.

In anyways thanks for the "service manager" suggestion, I am going to have to read/investigate on this side.

Looking at this I see you're writing a driver for Sonoff RF Bridge with Tasmota + Portisch. If you're in need I did write a method in Groovy to convert from B1 to B0. There's also other things which may be of interest to you here:

@markus
Thanks man actually I had a look at you driver / app and it's very cool, but for my simple use case it's way to complex. I just need it for replying per-captured codes for shades and switches.

In addition I wont to keep the base Tasmota + Portisch images and manage to to everything with the REST API.

:slight_smile: I understand, my driver is meant to be as flexible as possible once it is completed. So that does add some complexity.

This part is something I do want to understand the reasoning behind, why not use my firmware, if you don't mind me asking? I ask this since I'm considering to, eventually, add MQTT client support as an alternative to using my firmware and have gotten the feeling that you're not the only one with this reasoning?
The only change in my firmware is that messages that would normally be sent to MQTT is sent straight to Hubitat. It is just an extended version of the existing REST API.
In fact, as long as you would only use the sending feature, my driver would work with the original Tasmota, but the issue then is receiving status updates and monitoring the health of the device.