RFXtrx

[Mastiff]

Krambriw, is there any way to do this: In my system I use the Viking sensors a lot (which you know). The problem with those is that a battery change usually gives them a new address. And I want my wife to be able to change that. The script where it's changed is easy enough, but of course she'd have to know the correct sensor ID. And then there's the event. Is it possible to make a way to capture events that aren't in the system? So if a new sensor is added the event will be captured to a macro with the time and date of when it came in, and then it can be moved/copied to the main temperature control scripts as an event? Am I making any sense here?

[krambriw]

Possible yes, and agree, it is a mess that they do change id when you change battery (if you do it fast, eventually one-by-one, at least Oregon keeps the id)

Assuming some python scripts needs to be written....below are just my first thoughts

1) A new sensor is detected, capture this with a python script, check if it is unknown so far and then store relevant info somewhere (you loved using registry, right)

2) Have your control scripts to read your registry while looping and detect if a newcomer is there. What should now happen, what previous id is being replaced? And what is happening with collected data so far? For the graphs you would also have to manually update the settings with the new id of the sensor

All this mess is due to that sensors are changing id's when changing batteries, the advantage of 1-wire networks becomes clearer...

Best regards, Walter

[Mastiff]

Well, I only use registry to keep info from reboot to reboot, so that's not really the place for this. I think the coolest would be if it could be written to a file that can be accessible from a shortcut (I guess a plain txt file would be simplest, right?). If the format then is the correct to create a new event, that would probably do it. Then I could write a "how to" step by step guide to use that to change both the climate setup and everything else. Automatic replacement is neat, but the chance for messing up is probably to great.

Btw I define the different sensor in a startup script. Can I use the defined name there in the climate control setup, as a variable? So "Living room" instead of 634578? That would take care of one step.

[krambriw]

So "Living room" instead of 634578? That would take care of one step.

Currently I need the id of the sensor. Otherwise I would have to build some support for the same conversion table...

[Mastiff]

OK, so it's not possible to use a variable? The conversion table creates a table with global variables.

Code: Select all

eg.globals.Romkonvertering = {
    43008:"1",

and so on. 1 is the WC, since that's the first room in the house when you go in the main door.

[krambriw]

Regardless how you convert, the problem is that the id changes randomly when you change batteries in the sensor so you have to make this manually somewhere, the system cannot by itself know what the new id is

[Mastiff]

Aha! You misunderstood me! I mean that I use the variable in everything BUT the conversion table, so it only has to be changed that one place.

[krambriw]

Thinking a few days about this problem, one way of handling this is to never use the original events from sensors that have this "feature" that they are changing id's after battery replacements

What I think could be a solution is to have a python script that you trigger with the original sensor events and that those are internally converted (using a table) and re-issued with a room name or other fixed labels that never change. The new event is instead what you use in your remaining logic.

If you then have to change batteries, there is only one place you will have to update, your conversion table.

[Mastiff]

Smart thinking! I have a translation table at startup that translates the sensor number to a room number (rooms are in another table), fire the main script with the original event and then use the first lines of the heater control script like this:

Code: Select all

if (eg.eventString.split(' ')[1]) == "Viking":
    
    #Find the room from the table in the startup script
    Rom = eg.globals.Romkonvertering[int(eg.eventString.split(' ')[4])]
    
    #Find temperature and signal strength from payload
    eg.globals.Romtemperatur[Rom] = float((eg.event.payload.split(' ')[2]))
    eg.globals.Signal[Rom] = (eg.event.payload.split(' ')[6])
else:
    eg.Exit()

But your way is better, so I'll implement that instead! Thanks a lot! If I understand you correctly:

One "trigger script" for each room, triggered by the event from the sensor, and then maybe using "Trigger Event" with an event like Main.Tempsensor.Temp[1] for room 1 and so on, or the same thing in a Python script. Right? That should not be a problem in itself. But it does present two problems, maybe you can think of something for those as well?

1. The ClimateDataCalculation is dependent on a device ID. I don't know what that's used for, but how do I get around that? Can I put 1 (the room number) as the sensor ID?

2. Back to the original question: Is it possible to find a sensor that isn't in the trigger scripts in some way? In other words new sensors or sensors that have changed ID by battery change?

[krambriw]

1) The ClimateDataCalculation parses an event and finds the details in there. Like an event looking like this:

Code: Select all

19:11:19   RFXtrx.Type: THGN122/123, THGN132, THGR122/228/238/268 id: 8194 ' temperature: +18.5 deg C humidity: 58 %RH status: normal signal: 6 battery: 9'

If you would like to set your id as you suggest, your conversion script has to 'create' a new event with the same format but where you would replace 8194 with the room number as string, then it should work to use the same in the configuration for the sensor data capturing.

2) Of course you can find a new sensor but you have to compare it with a list of already known sensors. But you cannot know for sure which sensor it eventually has replaced. One uncertain way could be to monitor for sensors that are suddenly lost and match them with a new that suddenly appears. But the question is how reliable this will be? Is the sensor really lost or is it just temporary lost? And is the new one really yours or a neighbors?

[Mastiff]

Great, then I'll change my system to create an event connected to the room number, which triggers the rest of the stuff.

And I really don't mean an automatic system for changing the event with that unknown sensor, I just want a way to see in the log when there's a sensor that isn't in the room number list. The best way would probably be to have info written to the log, like "the previuos sensor, number xxxx which now shows xx.x degrees, is not in the list". That's all I need, because then I can look at the temperature on the small window of the actual sensor to control that it's the correct, missing sensor and change manually the first action that creates the room number event from the sensor number.

[krambriw]

connected to the room number

Just keep in mind that the new id shall not have any spaces. So if you have wanna use a new id for 'bath room 2', better make it 'bath_room_2'

[krambriw]

The best way would probably be to have info written to the log, like "the previuos sensor, number xxxx which now shows xx.x degrees, is not in the list"

Yes, either as event or simply printed. Anyway this can be handled by the script mentioned earlier

[krambriw]

Added support for Home Confort TEL-010
Improved support for PT2262:
- Action send_ELRO_Flamingo_Phenix_Sartano_RisingSun_Brennenstuhl renamed to send_PT2262
- decoding PT2262 (Lighting4) now includes pulse timing value

New version uploaded

[_RIGHT_H]

I just ordered rfxtrx and tried to download the plugin but the site is down