Ahoy,

As it's winter now, I have a NEXA radio-controlled wall socket to turn on the heater in my car remotely (manually or with a timer). Unfortunately, the glass facade of our office building appears to have some signal-blocking film in it and only on about 1 out of 5 tries I can get a signal out. As the socket is just a receiver, there was no way of telling whether the heater is turned on or not.

For this, I put a phone charger inside the car and connected it to my spare N900.
I set it to monitor charging state via dbus-scripts:
Here's on_AC.sh, thanks to Phone control wiki:
So, this worked well for some time. After a few days however, dbus-scripts stops responding to charger_connected even if it's restarted with killall dbus-scripts. A reboot fixes this. What could it be?
If killall worked, I'd just have a script restarting dbus-scripts whenever a call comes in from my normal number...

Also, do you have any ideas on how to monitor current charger-state? The only means of communication available is a phone call that is not answered, as it does not cost anything. Perhaps somehow monitoring if a call comes in from my own number, and then either rejecting it if charger is connected or forwarding it back to me if charger is not connected?

EDIT:
Was very nice for two winters, but then I thought I'd use the "car-phone" as a daily phone and it turned out it had suffered drastically, presumably from the daily temperature changes. GPS is inaccurate, tracks are just zigzag on straight roads, wifi reception has deteriorated as has cellular, it no longer tolerates any kind of overclocking, etc...
So I can't really recommend this to anyone.

1) After a certain amount of killall dbus-scripts invocations (or any other respawning init script) it simply stops respawning.
This is because it is desirable when say, Xorg crashes repeatedly and you want to get into a TTY.

2) IIRC phone calls also trigger dbus events. The entire phone system is dbus controllable in every way imaginable, so go wild.