PowerShell based cmdlets / Commands
Moderator: Telldus
Re: PowerShell based cmdlets / Commands
I'm afraid not, looks like the module has to be updated to support that.
Re: PowerShell based cmdlets / Commands
@ArneG Could you try the latest version (1.2.0) and check if it now works as you expect?
Get-TDSensorData and Get-TDSensorHistoryData should now hopefully post all values from the sensors "out of the box"![Smile :-)](./images/smilies/icon_e_smile.gif)
Get-TDSensorData and Get-TDSensorHistoryData should now hopefully post all values from the sensors "out of the box"
![Smile :-)](./images/smilies/icon_e_smile.gif)
Re: PowerShell based cmdlets / Commands
Does not work (as I expect at least)
The output from Get-TDSensorHistoryData is different from a rainsensor and a temperature/humdity-sensor, which cause problems when exporting both types of output to the same CSV-file (with -Append-switch). To get this to work I'll have to export rainsensor-histories and Temp/hum-sensorhistories to separate files. I would prefer all columns in one file with 'blanks' for rrate/rtot when the values are not present (not a rainsnsor) and 'blanks' for temp/hum when the sensor is a not a temp/hum-sensor.
I fixed this in 'my little workaround-Get-TDSensorHistoryData' like this by just appending the rainsensor-data at the end of each line:
(Does the same thing for the historydata as the workaround you suggested for the sensordata; "Get-TDSensor | Get-TDSensorData"-approach)
$PropertiesToOutput = @{
'DeviceID' = $DeviceID
'Humidity' = ($HistoryDataPoint.data | Where-Object { $_.Name -eq 'humidity' }).value
'Temperature' = ($HistoryDataPoint.data | Where-Object { $_.Name -eq 'temp' }).value
'Date' = (Get-Date "1970-01-01 00:00:00").AddSeconds($HistoryDataPoint.ts)
'RainRate' = ($HistoryDataPoint.data | Where-Object { $_.Name -eq 'rrate' }).value
'RainTotal' = ($HistoryDataPoint.data | Where-Object { $_.Name -eq 'rtot' }).value
}
$returnObject = New-Object -TypeName PSObject -Property $PropertiesToOutput
Write-Output $returnObject | Select-Object DeviceID, Humidity, Temperature, Date, RainRate, RainTotal
And I guess i will be much the same issue with $Sensordata when using a "$Sensordata=Get-TDSensor | Get-TDSensorData"-approach?
The output from Get-TDSensorHistoryData is different from a rainsensor and a temperature/humdity-sensor, which cause problems when exporting both types of output to the same CSV-file (with -Append-switch). To get this to work I'll have to export rainsensor-histories and Temp/hum-sensorhistories to separate files. I would prefer all columns in one file with 'blanks' for rrate/rtot when the values are not present (not a rainsnsor) and 'blanks' for temp/hum when the sensor is a not a temp/hum-sensor.
I fixed this in 'my little workaround-Get-TDSensorHistoryData' like this by just appending the rainsensor-data at the end of each line:
(Does the same thing for the historydata as the workaround you suggested for the sensordata; "Get-TDSensor | Get-TDSensorData"-approach)
$PropertiesToOutput = @{
'DeviceID' = $DeviceID
'Humidity' = ($HistoryDataPoint.data | Where-Object { $_.Name -eq 'humidity' }).value
'Temperature' = ($HistoryDataPoint.data | Where-Object { $_.Name -eq 'temp' }).value
'Date' = (Get-Date "1970-01-01 00:00:00").AddSeconds($HistoryDataPoint.ts)
'RainRate' = ($HistoryDataPoint.data | Where-Object { $_.Name -eq 'rrate' }).value
'RainTotal' = ($HistoryDataPoint.data | Where-Object { $_.Name -eq 'rtot' }).value
}
$returnObject = New-Object -TypeName PSObject -Property $PropertiesToOutput
Write-Output $returnObject | Select-Object DeviceID, Humidity, Temperature, Date, RainRate, RainTotal
And I guess i will be much the same issue with $Sensordata when using a "$Sensordata=Get-TDSensor | Get-TDSensorData"-approach?
Re: PowerShell based cmdlets / Commands
hmmm, I get what you mean but I think hardcoding the properties again is not a good approach for the module at least, as soon as someone buys another type of sensor it will be "broken" again, this problem is more related to exporting things to CSV instead of a format that handle different objects.
Actually, using the Select-Object method is probably the best way of doing this in any implementation.
That said, I'll do some thinking to see if I can maybe figure something out that will work for you... Hang on![Smile :-)](./images/smilies/icon_e_smile.gif)
Actually, using the Select-Object method is probably the best way of doing this in any implementation.
That said, I'll do some thinking to see if I can maybe figure something out that will work for you... Hang on
![Smile :-)](./images/smilies/icon_e_smile.gif)
Re: PowerShell based cmdlets / Commands
Yes, I do agree. From a neutral point of view the best approach would be to take care of various sensortypes dynamically. I myself will probably test also a windsensor in the near future
The problem (my problem at least) is mostly related to how I want the the exporting to CSV to work and how I want the data in the CSV-files to be organized. Maybe an useful approach (could also be useful for other users I guess), would be to implement some kind of parameter-system to let the scripts tell the sensor-cmdlets which specific fields/values that actually is to be put in the resulting return-object. (Parameters should be forced even if data is not present for a 'switch', resulting in a 'blank'. Somewhat like you already do in current code for temperature-sensors that may or not may provide humidity-readings)
As for now, I'm happy with my 'customized' 1.1.7-version![Smile :)](./images/smilies/icon_e_smile.gif)
![Smile :)](./images/smilies/icon_e_smile.gif)
The problem (my problem at least) is mostly related to how I want the the exporting to CSV to work and how I want the data in the CSV-files to be organized. Maybe an useful approach (could also be useful for other users I guess), would be to implement some kind of parameter-system to let the scripts tell the sensor-cmdlets which specific fields/values that actually is to be put in the resulting return-object. (Parameters should be forced even if data is not present for a 'switch', resulting in a 'blank'. Somewhat like you already do in current code for temperature-sensors that may or not may provide humidity-readings)
As for now, I'm happy with my 'customized' 1.1.7-version
![Smile :)](./images/smilies/icon_e_smile.gif)
Re: PowerShell based cmdlets / Commands
Ok, so I've updated the module again, it would be great to hear your opinion about the solution to this in 1.3.0. I've added the "ConvertTo-TDNormalizedOutput" cmdlet now which will make sure all objects have the same properties which should hopefully solve your issue.
Just pipe the results to that cmdlet before you export to csv and hopefully it will "just work".
Example usage:
What do you think about that? It will keep the default property names from Telldus for your rain sensors though. Do you think I should resolve rrate to RainRate etc. as well?
It should resolve rrate and rtot from version 1.3.1, makes more sense to me to have a more friendly name.
Just pipe the results to that cmdlet before you export to csv and hopefully it will "just work".
Example usage:
Code: Select all
Get-TDSensor | Get-TDSensorHistoryData | ConvertTo-TDNormalizedOutput | Export-Csv .\export.csv
It should resolve rrate and rtot from version 1.3.1, makes more sense to me to have a more friendly name.
Re: PowerShell based cmdlets / Commands
Almost there ![Smile :)](./images/smilies/icon_e_smile.gif)
Works fine when getting the complete history from all sensors, but when using switches -Deviceid and -After is does not work?
![Smile :)](./images/smilies/icon_e_smile.gif)
Works fine when getting the complete history from all sensors, but when using switches -Deviceid and -After is does not work?
Re: PowerShell based cmdlets / Commands
Probably because you're excluding sensors with those properties when you do that, if no sensor is reporting that type of sensor value, it wont be included in the results.
It will just make sure all objects have the same properties. I've done another update though (1.3.2), so now the ConvertTo-TDNormalizedOutput cmdlet has a "PropertiesToAlwaysInclude" parameter which should help you achieve that last use case.
Sample code:
Hope that will help ![Smile :-)](./images/smilies/icon_e_smile.gif)
It will just make sure all objects have the same properties. I've done another update though (1.3.2), so now the ConvertTo-TDNormalizedOutput cmdlet has a "PropertiesToAlwaysInclude" parameter which should help you achieve that last use case.
Sample code:
Code: Select all
Get-TDSensor | Get-TDSensorData | ConvertTo-TDNormalizedOutput -PropertiesToAlwaysInclude RainRate, RainTotal, Temperature, Humidity
![Smile :-)](./images/smilies/icon_e_smile.gif)
Re: PowerShell based cmdlets / Commands
Select-Object : The property cannot be processed because the property "Raintotal" already exists.
At AutomaTD.psm1:317 char:20
But resulting csv looks okay..
At AutomaTD.psm1:317 char:20
But resulting csv looks okay..
Re: PowerShell based cmdlets / Commands
That's what I get for using native .net instead to enhance performance
It's case sensitive, so it didn't think Raintotal and RainTotal was the same thing.
Updated version with (hopefully) a fix uploaded, also added friendly names for what I think are the correct types for wind sensors.
Hope it will work without any issues now!
Thanks for testing these updates out btw![Smile :-)](./images/smilies/icon_e_smile.gif)
![Bang Head :banghead:](./images/smilies/icon_banghead.gif)
It's case sensitive, so it didn't think Raintotal and RainTotal was the same thing.
Updated version with (hopefully) a fix uploaded, also added friendly names for what I think are the correct types for wind sensors.
Hope it will work without any issues now!
Thanks for testing these updates out btw
![Smile :-)](./images/smilies/icon_e_smile.gif)
Re: PowerShell based cmdlets / Commands
It isn't included? If you refer to the actual code it's not in the list of "Friendly names" because it's already called Humidity in the API ![Smile :-)](./images/smilies/icon_e_smile.gif)
![Smile :-)](./images/smilies/icon_e_smile.gif)
Re: PowerShell based cmdlets / Commands
Just an FYI - I just upgraded to a TellStick ZNet Lite v2 and realized that no events are "migrated" during the switch, all are left broken.
I've written a PowerShell script that can automatically fix all events so they work again (update the sensors/devices in all events so they match the new ones that Telldus "copied" to the new Tellstick).
I used that script to migrate all of my events and it seems to work flawlessly. If anyone have plans of doing the same thing and want to be a beta tester just ping me and I'll help you out (the script has only been used once so I'd like to test it a bit more before I release it for anyone to use).
The most important thing is that you run Get-TDDevice and Get-TDSensor and store all of that data somewhere safe before you remove your old Tellstick! (for example using Export-Clixml or Export-Csv)
Basically need to build a list of deviceids that should be changed (translate old deviceid -> new deviceid).
I've written a PowerShell script that can automatically fix all events so they work again (update the sensors/devices in all events so they match the new ones that Telldus "copied" to the new Tellstick).
I used that script to migrate all of my events and it seems to work flawlessly. If anyone have plans of doing the same thing and want to be a beta tester just ping me and I'll help you out (the script has only been used once so I'd like to test it a bit more before I release it for anyone to use).
The most important thing is that you run Get-TDDevice and Get-TDSensor and store all of that data somewhere safe before you remove your old Tellstick! (for example using Export-Clixml or Export-Csv)
Basically need to build a list of deviceids that should be changed (translate old deviceid -> new deviceid).
Re: PowerShell based cmdlets / Commands
Got my windsensor up and running today. Info will follow.