Thoughts and reasoning
Before updating and publishing the companion drivers for this firmware I'd like to ask what the best-practice approach is for the network ID of LAN devices on Hubitat? Is there such a thing as a best-practice yet? I'm relatively new here, I started about 1 month ago, so I probably haven't read everything. However, it does feel like it is still not very clear what the best approach is.
To be able to replace one device with another easily, using the IP seems like a great way. But this requires all devices to keep the same IP, so either static IPs or assigned IPs in the DHCP server would be needed.
MAC addresses will not change (normally) and even if the IP change, that can then be automatically updated. To replace one device with another, the Network ID would have to be updated manually.
When using MAC address matching, as I've understood it, it also requires the devices to not have their ethernet frames altered for the actual MAC to be seen by Hubitat. Is this correct, or have I misunderstood something? This would cause issues in many scenarios where NAT or IP routing is involved.
My suggested approach
I intend to do the following with the Network ID:
Let the user choose in the driver which matching to use: IP or MAC
For child devices I will use the parent DEVICE id, this way, switching between IP or MAC will not affect child devices. Event parsing is done in the parent device anyway. No matching is needed.
I would not do this. People will pick the wrong one every time. Pick what you feel will work best and go with it. If folks are smart enough to figure out that they want the other one, they're smart enough to modify the driver themselves. Make it simple because people are going to try and implement it who have no idea what a MAC address is.
That isn't possible. Each device has to have a unique ID. I would recommend the child be the parent's DNI plus dash switch number. So, if you had a sonoff dual, the parent would have a DNI like C0A80178 and switch 1 would be C0A80178-1 and switch 2 would be C0A80178-2. That way you can parse the message in the parent and send it to the correct child to sort out. The parent would just be the traffic cop for sending/receiving messages. All of the action of parsing meaning from the message or commands from apps would be handled in the child devices.
Thank you for the feedback. That is a valid point, how about making the setting to be something like "Is the device IP fixed and will never change, set this to true if you experience issues with getting updates". This way "power" users can use this setting to make it work, and the "normal" user won't set it unless they really have a fixed IP, in which case it doesn't matter if they set it or not unless they really have some filtering of MAC addresses done in their network, which only a "power" user would have anyway, most likely.
I think I didn't express myself very clear, I mean to use $device.id-1, $device.id-2 etc, where $device.id is the parent id (which is unique per device on the hub). This way, even if you ever switch between MAC or IP, it doesn't affect child devices.
Glad it helped, will have to see how to implement this in my drivers without confusing normal users and without requiring fixed IPs... Any thoughts on the above?
I found your info in the driver page enough to get it working. But maybe I am not a novice user so I can understand where @M874585684875 is coming from.
I've published some drivers as well as restructured how I create drivers, so it should be easy and fast to create more drivers without having a lot of redundant code to keep track of. This way, if I make a change to one of my drivers, it is automatically added to any other drivers using the same functions.
Currently I am running Sonoff Basic R3, Sonoff Mini also have a Sonoff Basic R3 Zigbee but I havent installed that as yet.
EDIT: I almost forgot I also use this one for a Tasmota plug I built with an installed / upgraded temp sensor I added. If this could be added i'd cut that over too.
Which module have you set Tasmota to for the Sonoff Basic R3? I have Sonoff Minis so that one I know. The Zigbee-based one would be outside of the scope for these drivers, probably need some special parsing. When I get to rewriting my drivers for all Xiaomi devices I have, I'm sure it would be easy to get that one supported as well, if you find a driver for the Zigbee based one, give me a shout and I'll add it as reference material for my future updates. I intend to have all drivers I use to be created using my own framework, that way I get consistency, adding some extra devices on the way just improves my over all code.
For temperature readings I'm not certain what is being sent since I have no temperature/humidity sensors with Tasmota. If you could run one of my drivers with logging set to "Reports+Status" and post the log, that would help. Make sure you see things in the logs regarding temperature and humidity. Also press the "Refresh" button of the driver. That may generate some additional messages which need decoding. Also need the Template or Module number for this one.
It seems the guys are getting buy with the generic zigbee HE driver so maybe that's enough.
Sure I can do that. btw I am using the Tasmota sensor version here so i'd imagine it will require re-packaging with this version too. In relation to the module it's a BME280 sensor see here.
Ok, so you have made no changes on the Tasmota device webpage? What I need to know is which module selection and if you've set a Template on the Tasmota webpage. If you have, I can make those part of the driver so that they are set correctly.
Then there is no need for anything special.
ok, will need the Template setting you're using in Tasmota so I get that to be part of the driver.
Yes, first 7 minimal if you're already on Tasmota, when going with Tuya convert, flash with 7 Basic first. After Basic you can flash with minimal and finally with the actual Hubitat firmware. Do make sure to use the firmware from the same release together, mismatching/mixing MIGHT cause problems.
Why would you try and flash Tasmota to the Zigbee version. The zigbee version doesn't have an ESP8266 chip. The zigbee based one works with the generic Zigbee switch driver out of the box.
Not talking about the firmware here, just the HE drivers. Since they work with the Generic driver, then there is no need to do anything. I have Zigbee devices which do need special drivers, like Aqara curtain motors. When I do get around to releasing Zigbee drivers for devices not working with generic ones, I will create a new thread for those to keep the confusion down...
