Javi

Node Def: <nodeDef id="MQSW" nls="SWITCH"> <editors/> <sts> <st editor="ONOFF" id="ST"/> </sts> <cmds> <sends> <cmd id="DON"/> <cmd id="DOF"/> </sends> <accepts> <cmd id="QUERY"/> <cmd id="DON"/> <cmd id="DOF"/> </accepts> </cmds> </nodeDef> Editor: <editors> <editor id="BOOL"> <range subset="0,1" uom="2"/> </editor> <editor id="ONOFF"> <range uom="78"/> </editor> <editor id="TEMPF"> <range max="176" min="-40" prec="2" uom="17"/> </editor> <editor id="HUM"> <range max="100" min="0" prec="2" uom="22"/> </editor> ........ </editors> Summary: Editor ID "ONOFF" is missing min/max or subset Added pull request for developer https://github.com/Trilife/udi-mqtt-pg3x/pull/16

Local access should work, however it is highly dependent on the device. Many devices, especially Apple devices, will not route traffic to a WiFi Connection without internet. So even if you force it to connect to WiFi it will not send requests. https://wiki.universal-devices.com/UD_Mobile#WiFi_Connections_without_internet

Perfect, Please post output of these 3 files: NodeDef, needed to get the editor ID from node def ID: http://192.168.XX.XX:8080/rest/profiles/family/10/profile/12/download/nodedef/nodedefs.xml Editor, needed to verify missing min/max or subset values: http://192.168.XX.XX:8080/rest/profiles/family/10/profile/12/download/editor/editors.xml Node: http://192.168.XX.XX:8080/rest/nodes/nodeAddress. where nodeAddress is the node address of any one of the nodes with the issue. Needed to get the Node Def ID

Thanks what slots number is the mqtt plugin?

Looks like the Node Server is missing a value. Please post the output of http://192.168.XX.XX:8080/rest/profiles/family/10/files. where 192.168.XX.XX is the local ip address

I don't recommend this for 5.x. Using scenes, like the fan example, is the recommended way.

I was referring to eisy, sometimes the battery parameter is included in a separate node

Check out the 5.x Keypad and Fan scene example https://wiki.universal-devices.com/ISY994i:INSTEON_Device:FanLinc-KPL_FanLinc_KeypadLinc_Configuration#Firmware_5.x Scenes will work better than programs and KPL buttons can not be programmatically controlled, they require a scene (insteon limitation). A scene with the KPL button will need to be created to turn it on/off. Programs should only be used for corrections, like the "Note" section after the main scene in the example, as there are no "Wait" conditions. Sending many Insteon commands rapidly (i.e. from a program) may cause some commands to be dropped by the insteon network, so it may not work as expected without waits in between commands. Although this is even more tricky as "Wait" makes eisy programs act as a "While" instead of "IF" so the program may not finish executing if there is a wait without the main program triggering "Then" on another program.

Not sure, is there sibling node with the battery level? The time is one of the reasons it's still beta, we had a formatting issue in the database. I think it should be fixed in the next firmware release, but not my specialty so I could be wrong . We also still need to implement a database purging as the database could become very large very quickly for some users.

It does: see Admin Console Please open a ticket

Likely not, ISY994 did not support Z-Wave secure communication. This is one of the reasons the device needs to be re-added.

These locks are a pain, I documented it somewhere but don't recall if I published. Basically the lock requires you to follow setup instructions exactly, the biggest step missed my most users was after factory reset you need to manually enter one of the default codes so the lock goes into the locked position then again so it unlocks. Only after doing this will the lock add into eisy. Also the range during interview needed to be very close, like a few feet.

Yeah, it is a pain if already released. There is no great way to identify a toggle, these assumptions worked the best for most devices of all types. The first version of UDM calculated this differently, If the command with ID="DON" existed and had an init equal to the Primary Property (ST if exists, if not the first listed) UDM would show a toggle. However cmd init requires a range, so devices without a range did not show a toggle in UDM. With that said, I am in the process of a major revamp of the app to replace deprecated APIs and simplify/enhance/speed-up some things. The new app APIs removed the toggle calculation from lower level and is now done at the UI level. So it could change easily when the new APIs are implemented into the Home Tab. I'm hoping to allow users to change the Primary Property on the Home Tab (like favorites). So it may be better to use the original calculation first if DON has an init value, and use the existing calculation if DON does not have an init value.

The UOM should not affect this calculation. If there are command IDs DON and DOF and a property id "ST", then the app assumes this is a device which supports toggle. If the ST property has a value greater than zero it assumes on, else assues off. Based on the screenshots if "Outlet State" has the id "ST", then value 0 is off an 1 is on. So the toggle should work. Maybe the value was not published quickly enough and user did not see change?

Hard to say, I need the first screenshot for both on and off. If the toggle indicator (circle on the top left) is filled UDM believes the device to be ON, if empty it believes the device to be off. UDM's calculation of on/off status may be imperfect as not all nodes are the same. While there are a few exceptions UDM will show the status indicator (empty/filled circle) and allow toggle if there is a Property with the id="ST" and the node supports commands on (id =DON) and off (id=DOF) commands UDM assumes the Property with the id = "ST" correlates to these commands.