I’m developing some drivers for Arduino based devices I’ve got in my home. With the Arduino software I have attributes (preferences) I can set with the device wifi setup to identify if the device is to use Prod or Test values (like port numbers, so I can test on my home network and not affect the devices marked Prod). With the Arduino’s I only push the code to the Prod devices (the ones my wife interacts with!) once I’m done testing the devices I have in my office.
Any recommendations on how to set up my Smartthings drivers so I can keep my test code only working with test devices? I’m thinking I’ll put in a preference that via settings I can set to Prod or Test to cause behavior difference in the code (like port numbers to use on the network). But how to keep the actual code pushes I do to the hub separate? I’m pretty sure I’m going to need two driver ID’s, but I only want one code base. Do I set up two directories - one for Prod, one for Test, and a third directory that has the shared logic in it. Then I could just publish from those directories as wanted. What would be in the “stub” that I have in the Prod/Test directories? I don’t see an equivalent of a “copy” or “include” statement to use in Lua.
Can this be done via playing with the version info - maybe just add Test or Prod to the version info? How does this affect driver id, etc?
I think you can keep one code base and have two config.yaml. The driver ID appears to be hashed from that file. You would want a different packageKey and name to indicate your test env. Not sure if the CLI allows you to pass in your config.yaml on the command line, but that would be ideal. If not, you can solve it by having two workspaces share the code via symlinks or a sub-repo.
Hi, @edleno!
I’ve seen others create two driver channels, one for the “public” and another for tests.
This is because, if you package and publish/assign to the channel a new version of the driver, all the devices enrolled there will receive the update up to 12-hours later (it can be faster).
This way, you avoid publishing changes that you haven’t tested for the prod devices.
I do want two versions on the same hub. I’m thinking having two channels on the same hub doesn’t let me do that, certainly seems that driver ID is what makes the difference - unless it’s the concatenation of channel and driver ID?
Currently, I have 3 channels… Private, Beta and Public.
I use Private to make my own tests.
I use Beta to get some help from other users that own the device.
I use Public when things seem stable enough.
For the latter two, I use this workflow to control the publishing process.
I don’t know whether this is the best approach, but it is working for me.
@w35l3y This is indeed a more consumable option, thank you for the information. I have already incorporated these actions into my repo.
Because I have multiple drivers in the same repo, I went a few steps further to trigger the publish jobs based upon the path that is being updated. I have now used this to build different drivers within the same repository. – Thank you.
One thing to be careful with is custom capabilities. There isn’t a way to isolate those to a specific channel unless you want to designate different IDs for each environment. If you update a capability, it will hit every user, regardless of channel enrollment or driver being used.
