Simplistically, I think of it this way.
A sensor can report on what it is tasked to measure. That could be tyre pressure or temperature or both. It can react to it’s data - for example, it might be programmed to report an alert if above/below a threshold. It cannot act on that data in a control way - it can’t run a pump to inflate the tyre for example.
A sensor needs to have an “interface”. That can be simple, I2C or SPI, or it can be complex, CAN, RS485, serial, Bluetooth, RF, TCP/UDP, HTTP… but the data you can get is “simple” - just what the sensor can read.
<insert grey area here >
A embedded device can use sensors, or aggregate data from multiple sensors, and act in a higher manner. This might mean it can detect the temperature, but may also be able to perform actions on it, turning on a fan or heater for example, or it can tell the temperature from one sensor and the fan RPM from a different sensor and can then calculate the required voltage to change the fan speed to achieve a temperature.
As an embedded device is usually operating at a higher level than a sensor, it often is interfaced at a higher level as well - so it may be “human readable” and not just machine-2-machine readable. This means it has a higher-level interface and not just a way for an upstream system/device to see the value.
simple, eh !