Mixing atomicState and state

[stephack]

@kevin

App

definition(
	name: "atomicState minimal",
	namespace: "ukusa",
	author: "Kevin Hawkins",
	description: "Testing atomicState",
	category: "My Apps",
	iconUrl: "https://s3.amazonaws.com/smartapp-icons/Convenience/App-BigButtonsAndSwitches.png",
	iconX2Url: "https://s3.amazonaws.com/smartapp-icons/Convenience/App-BigButtonsAndSwitches@2x.png",
	iconX3Url: "https://s3.amazonaws.com/smartapp-icons/Convenience/App-BigButtonsAndSwitches@2x.png"
)


preferences {
    section {
		input "mqtt", "capability.telnet", required: false, title: "Device Minimal", submitOnChange: true 
    }

}
		
def installed()
{
	log.info "${app.name} Installed"
	initialize()
}

def updated()
{
	log.info "${app.name} Updated"


	initialize()
}

def initialize()
{
	unsubscribe()
	log.info "${app.name} Initialized"
	subscribe(mqtt,"addDev", createDevice)
	atomicState.count=0
	atomicState.counter=0
	atomicState.devlist=""
	mqtt.initialize()
	pause(1000)
	mqtt.createDevs()
	runIn (1, "devSummary")
}

def createDevice(evt) {  //TODO merge with above
	atomicState.count++
	local=atomicState.counter
	local=local+1
	atomicState.counter = local
	atomicState.devlist += evt.value
	log.debug "Event from device ${evt.value}"
	}



def devSummary()
{
	log.debug "atomicState.count is ${atomicState.count}"
	log.debug "atomicState.counter is ${atomicState.counter}"
	log.debug "atomicState.devlist is ${atomicState.devlist}"
}

driver

metadata {
		// v0.1
    	definition (name: "MQTT minimal", namespace: "ukusa", author: "Kevin Hawkins") {
        capability "Initialize"
		capability "Telnet"  // temporary kludge as no mqtt capability yet
			
		command "createDevs"
    }

    preferences {
        // put configuration here
    }

}

def installed() {
    log.info "Installed"
}

def initialize() {
	log.info "Initialised"
	state.devices = ["A","B","C","D","E","F","G","H","I","J","K","L","M","N","O","P","Q","R","S","T","U","V","W","X","Y","Z"]
}

def createDevs () {

@kevin

So let's all have a laugh

Nothing to contribute here. I've just been following this thread so I could learn more about atomicState vs state variables and since I can't give you a solution I figured I'd give you what asked for .

[kevin]

Maybe it's not such an atomic era

[chuck.schwer]

@kevin

My device driver delay routine / loop is horrible too, can’t we have a better option like sleep()

what are you using? I guess not pauseExecution ?

[kevin]

I'm using this from an old ST post by Terry (ActionTiles)

• should I be using pauseExecution ?

  def pause(millis) {
  def passed = 0
  def now = new Date().time
  /* This loop is an impolite busywait. We need to be given a true sleep() method, please. */
  while ( passed < millis ) {
  passed = new Date().time - now
  }
  }

[chuck.schwer]

@kevin

should I be using pauseExecution ?

Yes you should be
The method you posted puts unnecessary load on the hub. I'm wondering how many people are using something like that?

[kevin]

@kevin

pauseExecution

sorry I missed it .. where is it documented ?
Google was not my friend
I assume it takes a single parameter in mS

[chuck.schwer]

@kevin

sorry I missed it .. where is it documented ?

The post above has a link to it (click on pauseExecution):

@chuck.schwer

I guess not pauseExecution ?

[kevin]

Thanks - and no possibility to disable or hide devices ?

[chuck.schwer]

I'm not sure what you mean.. you want to hide devices from the user? in the main devices list? If so, then no.

[kevin]

I wanted to hide them from the user or disable them like the 'disable' checkbox does. One way they would be totally hidden except for getChildDevice() etc and the other they just don't function. Not a problem but that would have been an easy solution as there are 150 devices involved (for me) and they clutter the interface currently.

[srwhite]

Why don’t you just filter the devices at creation time and only create the ones you need?

I for one think it would be a very bad idea for apps and devices to be able to hide devices. That concept has the potential for serious abuse.

[kevin]

Initially it was because I couldn’t create a valid input drop down to select from, now using a delay in my device driver I can.

Also still as an obstacle is the deviceID, label and capabilities all arrive separately, and I need to match them up before creating the device. I’m on the way to being able to implement this though now.

Having disable as is already implemented in the UI would be useful but yes, I can also see issues with hidden.

K

[stephack]

@kevin

Initially it was because I couldn’t create a valid input drop down to select from, now using a delay in my device driver I can.

It's very difficult to provide feedback without seeing more of your code and you probably don't want or need any....you are obviously a more proficient programmer than I am. But based on the pieces I'm putting together from this thread, it sounds like you are trying to do things in the driver that might be better accomplished in the app portion of the code. For instance, your device list could be stored in a map or list and presented as an enum input where the user could select the drivers they want created.

I realize I am making a lot of assumptions above but it just seems like it should be possible and would make timing the device creation easier and avoid needless cycles creating unneeded devices. Just my 2c.

[srwhite]

@kevin

Also still as an obstacle is the deviceID, label and capabilities all arrive separately, and I need to match them up before creating the device. I’m on the way to being able to implement this though now.

Thats where I would focus my energy if I were in your position. If you can't change the serial nature of the data coming in, you can at least cache it in state and then create your devices once you have all of the needed components.

[kevin]

@stephack

For instance, your device list could be stored in a map or list and presented as an enum input where the user could select the drivers they want created

Indeed I can now do that using the small inserted delay that has got the list 'stable' - before it was being mangled even using atomicState

@srwhite

you can at least cache it in state

I couldn't actually as it arrived asynchronously and too fast so state was inconsistent. Even too fast for atomicState , which is not bullet proof. By using a tiny delay of 50mS I now have it robust though so, once more I'm all set to proceed.

This is the nature of MQTT - if you subscribe to a wildcarded topic to retrieve say a list of devices you will get a load of payloads returned instantaneously in a burst of individual messages. In my case over 150. Payloads e.g. labels' arrive together but the devices they apply to are all interleaved.

I'm on the right track now though.

I've also been considering whether it would be useful to present MQTT devices to other Hub Connect clients directly for selection. Of course creating a device on HE facilitates this anyway.

[srwhite]

@kevin

I couldn't actually as it arrived asynchronously and too fast so state was inconsistent. Even too fast for atomicState , which is not bullet proof. By using a tiny delay of 50mS I now have it robust though so, once more I'm all set to proceed.

A word of caution... It you are using atomicState to store data with continuous high-frequency access (reads and writes to the database) you will inevitably create a “hub killer” app. Hopefully you’re able to avoid that.

As I visualize this I still think you can use state for this with a periodic runIn job to marry up all of the arriving data parts leading to device creation. It’s just a thought based on my very limited of what you’re trying to do.

@kevin

I've also been considering whether it would be useful to present MQTT devices to other Hub Connect clients directly for selection. Of course creating a device on HE facilitates this anyway.

I gave some thought to MQTTA integration with HubConnect but inevitably ran into the same challenges you are facing. I just couldn’t visualize how I could emulate the same or at least similar user experience.

I’m open to suggestions if you ever want to take a crack at it.

[kevin]

@srwhite

A word of caution... It you are using atomicState to store data with continuous high-frequency access (reads and writes to the database) you will inevitably create a “hub killer” app. Hopefully you’re able to avoid that.

Fortunately It’s just the startup of the app that needs to model the incoming messages. Maybe the first 30 seconds, and then only if you are using MQTT discovery. Once that is complete I don’t think I ongoingly use atomicState at all so this isn’t an issue. State would indirectly create much the same effect.

I’ll keep pondering about MQTT and HubConnect...