Since the most recent update, I'm seeing errors when trying to change a previous app I added.
I have a trigger that looks at the temperature of a sensor. The sensor supports integers with decimal places. So I have a trigger that looks like this: Temperature of Living Room Sensor becomes = 68.5.
When I try to edit that trigger now, I get the following error in the logs:
2019-12-09 09:57:05.980 am errorjava.lang.ClassCastException: null (selectTriggers)
2019-12-09 09:56:10.106 am errorjava.lang.ClassCastException: java.lang.Integer cannot be cast to java.lang.String on line 638 (selectTriggers)
I suspect that this is being caused by the decimal but I'm not totally sure. I'm trying to avoid re-building the app without decimal spaces but I'm wondering if this is caused by the recent update.
EDIT: Here's my Hubitat Platform version: 2.1.7.121
"Integers with decimal places" are not integers, though - are they? There is no such thing as an "integer with decimal place".
Feel free to post the code if you would like. Certainly seems like it is expecting an integer and getting a float... Which I would EXPECT to give an error.
I created the rule using the UI, so I'm unsure if I can export the app code in any way. It'd be lovely if I could, then I could just change the floats to ints and be on my way.
I don't think this has anything to do with the update or using integers vs decimals. More likely, something is corrupted in this rule. Could you show me the Settings portion of the App Status page (gear icon).
You might want to download a backup of your hub, and then do a Soft Reset and restore from that backup. If that doesn't clear it up, let me know.
You're right; I reverted to the previous version and the same behavior exists on that version. I actually just got it to allow me to edit the Trigger. Oddly, when I edited the Actions for the Triggers, THEN tried editing the Triggers it allowed me to.
I've since updated the Trigger rules and it seems to be working now.
I have a question.. Why are your triggers all equal to exact numbers? This rule would not fire if the temp went from 71.2 to 70.9 for example, which is not outside the realm of possibility. It would only fire when the temp was exactly equal to 71.0. So, I would suspect that this rule fires once a day when your mode becomes morning. That's it.
If it skips over the numbers defined in your trigger, the rule will not work correctly.
You see from 20:00 - 07:00, heat (red annotated lines) comes on pretty regularly when temp (green line) drops below ~67 or so and shuts off when the temp reaches ~70.
Surprisingly it seems to work like a charm! Also, this chart is from a different app, configured the same way as above but with different triggering temps.
Edit: OR it doesn't need the Temp Triggers at all and the IF statement just gets evaluated live?
you mean, the thermostat is set to heat? Where are you capturing that?
where are you capturing the thermostat mode?
Or this could just be your thermostat doing it's job. If you have a thermostat controlling the heat, it will stop heating when the temp goes above it's setpoint. That's the point of having a thermostat in the first place. Why do you need to change the mode? If the temp is 80 and the thermostat is in heat mode that doesn't mean the heat will be on.
I mean, correct me if I'm wrong @bravenel but if you have a sensor that goes out to 2 decimal places so the value of 70.13 for example, if i compare that in rule machine to 70.0, will not those match as equal to each other, correct? And a trigger event would not occur, correct?
Based on this graph, you can see that it definitely occurs in the morning, by the mode change. But then the trigger never occurs to turn the heat off. It blows right past 71.0 and goes to the setpoint. Your graph shows that it's not working.
you mean, the thermostat is set to heat? Where are you capturing that?
I don't use the Auto setting, It's either Off or on Heat setting during this schedule. The red line is when the Heat is on.
Or this could just be your thermostat doing it's job. If you have a thermostat controlling the heat, it will stop heating when the temp goes above it's setpoint.
Nope, not the case here. It's either Off, Heat, or Cool depending on the app.
How do you explain the spike almost to 80? Shouldn't the rule have shut it off at 72?
That was actually a mistake on my part, this app is only activated when it's in a certain bedtime mode. That mode exits at 7:00 AM. If it's in Heat mode at 7:00AM then it will stay in Heat mode. Actually that spike is what the heat would look like all night if the app weren't working. I leave the thermostat on 75 all night and simply control the Heat/Cool/Off mode purely with the app based on the temp of the sensor.
Edit: I also turned on Trigger logging for that app, so I'll find out if the app is being triggered for sure but I'm fairly certain it is.
A thermostat in Auto mode means it will switch between heat and AC automatically. Not that it will turn the heat and and off automatically.
You do realize that when your thermostat is in heat mode, it's not producing heat constantly, right? When your thermostat is in HEAT MODE it turns the furnace off after it heats the house to the setpoint that you've chosen. Then it turn it off. Once the temp in the room drops again, it turns the furnace back on. That's how a thermostat works. Being in Heat mode does not mean that the furnace is on and producing heat constantly. That's not how it works.
Well, Bruce would disagree. This rule is only ever going to trigger at EXACTLY 69.00, 71.00 or 72.00.
But your trigger is that mode BECOMES morning.
So, you bedtime mode is Morning?
I'm really not sure why you're so obsessed about this and frankly being rude when I never even asked for your help or input but...
I know how a thermostat works, yes. But what I'm telling you is that my heat is set to 75, I literally watch it turn to Heat and turn Off every evening on its own based on the app I have above. I don't know what else to tell you. Unless a ghost is setting the Thermostat mode to Heat and Off every night, I assume the app is working as I expect it to.
Well then perhaps the sensor does report back when it hits exactly 69.00, 71.00 or 72.00.
I mentioned before the charts are configured or a different app, not the one I original started this post about. Actually none of this is about what I originally started this post on.
I'm not asking for help with this, it works for my needs
There is no such thing as an "integer with decimal place".
