Yesterday at 08:12 PM1 day I have Sensibo plugin installed on eisy running 6.0.3I noticed that the temperature in the space dropped below the setpoint in a program to trigger heat mode, but the unit didn't turn on. When I signed in to the admin console, the none of the Sensibo nodes where populating.Next I checked pg3x and while the configuration screen looked fine, plugin wasn't responding and the log didn't populate. I reinstalled the plugin in the same slot and everything came up fine. However, I noticed the Power State in the admin console was reading 0 degrees F. In pg3x the Power State is listed as GV2 and a UOM of 17, which is used for other temperature settings.Turning the unit on, the Power State updates to 1 degree F.Something appears incorrect?As a follow up to my initial post, I have eisy count runtime utilizing the Power State. In a program, the values available for the Power State are on & off, making the counter program inoperable. Edited yesterday at 08:18 PM1 day by DennisC Added on value & programing counter information.
5 hours ago5 hr This is one of the plug-ins that I ported over from PG2 to PG3 for UDI. I don't have a Sensibo so I'm not able to do any debug/testing on this plug-in but I do try to fix bugs when possible.Since the plug-in uses the Sensibo cloud API, it's very possible that if it fails to connect to the cloud service that it will stop working and need a restart. That should show up in the log. Note that PG3x won't display historical log entries, you'd have to download the log to get the entries prior to is hanging/stopping.The profile files have GV2 using UOM 25 and restricted to values 0 and 1 with those mapped to Off and On. This matches what's defined inside the node itself: {'driver': 'GV2', 'value': 0, 'uom': 25, 'name':'Power'}, which is what PG3x should be displaying. I have no explanation for you seeing GV2 with UOM 17.
2 hours ago2 hr Author 1 hour ago, bpwwer said:The profile files have GV2 using UOM 25 and restricted to values 0 and 1 with those mapped to Off and On. This matches what's defined inside the node itself: {'driver': 'GV2', 'value': 0, 'uom': 25, 'name':'Power'}, which is what PG3x should be displaying. I have no explanation for you seeing GV2 with UOM 17.Thanks for both porting this over to pg3x and for responding.I did a comparison of the UOM values listed in sensibo_node.py and pg3x, besides GV2 showing 17 instead of 25, I also found the following discrepancies (clarification - I compared UOM values from github to pg3x):CLISPC - pg3x UOM = 17 instead of 4CLISPH - pg3x UOM = 17 instead of 4ST - pg3x UOM = 17 instead of 4Let me know if there is anything I can do to correct this.Here are some screen shots of what I see. Edited 2 hours ago2 hr by DennisC added clarification of comparing github UOM to pg3x
45 minutes ago45 min It is supposed to look at the units that the sensibo is set to and dynamically determine which units to use (C or F) when sending updates to IoX. I don't believe that PG3x's node display is dynamic so it should just be showing the initial units that the plug-in defaults to before it gets any updates from the sensibo. But that's not something I've ever looked into.The plug-in's debug log level should include messages showing what data is coming from the sensibo. There's nothing in the plug-in that is modifying the UOM of the power state. Looking at the PG3x log should show what the plug-in is sending to IoX when GV2 is updated. I don't believe it should be sending any UOM, so it should be defaulting to default UOM which is 25. If the log shows the plug-in sending the wrong UOM, then it may be a bug in the plug-in -> IoX interface library. If it's not, then it may be bug in IoX.
Create an account or sign in to comment