This would be a pretty simple virtual driver to write, but there's an even easier approach that seems like it would meet your needs. Have you considered using hub variables instead? webCoRE can make use of these directly.
You could use my Generic Attribute Driver I wrote a few years back as a starting point or at least a reference for how you could setup some elements of the driver you want to create, if you are interested in writing one yourself. That's not to say my code is a model of good practices or methods to develop something like this, but it will hopefully give you a start.
A minor point but you could use an app instead of a driver. Drivers are typically intended for devices. For example, I use an app that calculates circadian lighting values throughout the day. It saves those values to a hub variable that my lighting controller then uses.
The left variable_names won't be editable. The right number (setpoint) needs to be able to be edited either by clicking the +/ā buttons and through webcore.
Ideally able to have a pre-set initial set of values.
That's it.
Doable?
I imagine an app isn't the way to go, but I'm really not sure.
I take it there's no easy way to modify this to add the plus/minus buttons...?
If that's too much aggro, then I was wondering if there's a way to have the 'current states' completed automatically when the device is created? i.e. no states are listed until you manually set them and I would like to auto-populate these on creation of a device...
/**
* Generic Attribute Storage Driver
*
* Copyright 2019 Simon Burke
*
* Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except
* in compliance with the License. You may obtain a copy of the License at:
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing, software distributed under the License is distributed
* on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License
* for the specific language governing permissions and limitations under the License.
*
* Change History:
*
* Date Who What
* ---- --- ----
* 2021-03-07 Simon Burke Original Creation
* 2021-03-07 Simon Burke Added Refresh capability so that devices would appear in Maker API
* 2021-03-08 Simon Burke Change Refresh Capability to Actuator, which also allows for running custom commands
*
*/
metadata {
definition (name: "Generic Attribute Storage Driver", namespace: "simnet", author: "Simon Burke") {
capability "Actuator"
attribute "0900_0929", "number"
command "set0900_0929", [[name:"0900_0929", type: "NUMBER", description: "Setpoint for this time" ] ]
}
}
def refresh() {}
def updated() {}
def set0900_0929(numberValue) {
try {
sendEvent(name: "0900_0929", value : numberValue);
}
catch(Exception e) {
log.error("0900_0929: Error storing string value ${numberValue}, the error is ${e}")
}
}
Hmmm... Depends how "botched" you want it to be... Actually that's not true.... Personally I would suggest setting up commands / methods to move the attributes you need up and down, then create a virtual button completely separate to this device that calls those commands/methods in an automation when button X is pushed... Alternatively you could build in the button capabilities to the driver... but it may become a little complicated...
Being lazy, I would suggest playing with including code in both the initialized and updated methods... My money would be on initialized, but expect it is also called when the hub restarts, so would suggest including a check for a current value existing before setting a default.
EDIT - installed seems to be the one to choose, looking at the documentation...
Awesome, against all odds I'm actually getting somewhere with this
I could really simplify some of my heating system 'code' (I use that term loosely, it's a spider-Web) If I can figure out how to add a couple of switches.
From what I can tell though, it seems you can only have one switch per driver?
The code is in webcore, and it's a long list... I'm sure there's a better way. Any thoughts welcome, I really just need to know if there's a way of having the driver take action if any one of a selection of its own states change.
This (switches) seems to stepping outside of your original request... which is fine.... I'm not trying to be pedantic (this time ). It feels like it may be worth explaining a little more about what you are wanting to achieve. By that I mean, don't speak so much in what you are trying to do technically in the driver or with code in webcore, but what outcome are you wanting to achieve in "real-life". As an educated guess I am thinking you are trying to either chase short-term energy charges imposed by you supplier, and/or satisfy comfort requirements based on a combination of presence and manual personal preference for heating/cooling, with switches signifying a manual override? Once we know some of these details, then we can start to place some of the features of the driver to what they are solving. (It is hard not to sound too much like I am at work in these kind of comments ).
But to answer your more direct question, for all I know, yes, you can only have one switch attribute for a driver. Again, would be useful, once you explain the background, to know then how you intend this to apply these switches and what other options may be on the table.
I wasn't meaning that you couldn't discuss them here, just trying to use it as a catalyst to step back to look at the broader project. Whether you do that here or in another thread doesn't bother me. I think it sounds like it could be an interesting project and could even be useful for others if it could progress further, even with an app eventually.
Perhaps what you could do for your switches would be to keep the attributes you showed earlier and implement the button capability, passing in a different button number for each setting. You could either have a push event toggle the setting or use push and say hold to signify on and off.
At the moment my time is limited and seriously, trying to explain/ask questions about this mental little system I have cobbled together would be difficult to say the least.
What's the phrase... "sorry about the long letter, I didn't have time to write a shorter one". Extremely appropriate in my case. It works, but it's a mess. Anyone with an ounce of programming knowledge could probably sort out this rats nest in a day or two. But... It works.
I agree though it's an interesting project and it would be far better served via app. However, I've always been a fan of getting things up and running, and concentrating on simplification later, if there's time.
To give an idea of what this whole thing was about: basically I have created a fairly decent remote thermostat for, well, pennies using a node mcu and some cheap components. This allowed me create a multi room nest-style system, with actuators on every rad in the home for an incredibly low cost whilst being 100% reliable. The down side is that this is all controlled by webcore and, although the basic functionality (30 min boost etc) is perfectly user friendly and doable through sharptools, the actual editing of hourly (or in this case, half hourly) setpoints requires the editing of a Piston.
The idea was to create a really easy way to set the setpoints via a nice big UI instead of webcore. This however required a way too hold the setpoints, hence this butchering above.
). It feels like it may be worth explaining a little more about what you are wanting to achieve. By that I mean, don't speak so much in what you are trying to do technically in the driver or with code in webcore, but what outcome are you wanting to achieve in "real-life". As an educated guess I am thinking you are trying to either chase short-term energy charges imposed by you supplier, and/or satisfy comfort requirements based on a combination of presence and manual personal preference for heating/cooling, with switches signifying a manual override? Once we know some of these details, then we can start to place some of the features of the driver to what they are solving. (It is hard not to sound too much like I am at work in these kind of comments 
