When you use Item xxx changed as a trigger, previousState is an implicit variable holding the Item’s state before the change, even if no persistence is configured. So it should be perfectly fine to use in this scenario.
1 Like
Rather than show us the logInfo output from your original rule that would show your temperature Item’s actual state, you’ve now taken that logInfo line out of your rule.
It’s not casual nosiness - I think you might be struggling with UoM.
Testing yours, and it returns me this: Configuration model ‘notifications.rules’ has errors, therefore ignoring it: [57,50]: mismatched input ‘-’ expecting ‘)’
[57,63]: no viable alternative at input ‘)’
Edit; rossko, the previous rule didnt output anything in the log. Except for the temperature itself. Nothing else.
Rules interpreter can be bit funny about hyphen - depending on situation.
Sometimes you have to force a negative number like
fred = 0 - 1
Which is exactly the secret message I’m looking for. Does it say 22.5 or 22.5 °C ?
I am concerned that your Item may be either a Number type or a Number:Temperature type - which require different handling in rules - and we have seen no clues - not one state or Item definition - either way.
2019-11-05 19:49:52.533 [INFO ] [marthome.model.script.Outside_Temp: ] - 6.0 °C
2019-11-05 19:49:52.535 [WARN ] [.eclipse.smarthome.model.script.temp] - cold?
Thats the output, sorry i didnt realize it mattered.
Okay, I don’t know how you formatted the logInfo() to produce that now - but I will guess that it wasn’t you that added °C
The implication would be that your Item has units of measurement, UoM, and is not just a number.
You could also actually check the type of the Item involved that you defined, as already pointed out.
1 Like
Wow, that did the trick indeed! It works! But ideally, i should be using @noppes123 solution with this fix. As now it is spamming me everytime the temperature is received from mqtt, wich is quite often.
Also, can i include the exact temperature in the push notification sendt?
Anyone that can help me with that?
Yes you can…
Why don’t you have a go and let us know if it’s not working
You will learn nothing by copying and pasting our code
You will learn tons by trying to write your own
2 Likes
I figured it out 
Ended up with the following, probably better solutions to this, but it works.
rule "Freezing alert"
when
Item Outside_Temp changed
then
if(Outside_Temp.state < 0 | "°C" && previousState > 0 | "°C" )
{
sendNotification("email", "Det er nå minus: " + Outside_Temp.state.format("%.2f") + " °C")
logInfo("[INFO]: Temperature outside","Below zero")
}
end
1 Like
Good, please tick the solution post, thanks
Just out of curiousity (since I don’t fully understand this piece of code), what does the pipe character do here?
It tells the DSL compiler to use UoM
DSL: Domain specific Language (The language used for rules)
UoM: Units Of Measurements
To put it another way, that is all one “variable”. Not a number, a temperature. Not just 0 , but 0°C
The pipe bar ("|") is the unit delimiter used in the rules DSL for separating the Number from the AbstractUnit when defining a QuanityType.
Originally, this was []…
The OH documentation has a general discussion of Units of Measure and also details on the use of QuantityType in the rules DSL. The helper library documentation has an example of defining a QuantityType in scripted automation.
Ok… but which difference does it make in this context? Is there any difference between comparing Outsite_Temp.state with this as opposed to comparing to just zero?
Because apples don’t compare with oranges. If you compare a temperature with a number, it makes no sense.
“Is the current temperature above 15?” is nonsense without saying 15 what - C? F? K?
But I make comparisons like that all the time in my rules… Is it a matter of how the Item is set up?
Yes. Is your Item just a Number or is it a Number:Temperature
Ah. Yep, they’re all just Number. I’ll put on my remember-list not to ever change that, seems like it would break quite much here 
Thanks for the explanations!