PowerShell based cmdlets / Commands

Moderator: Telldus

c8h10n4o2
Posts: 73
Joined: Thu Jan 18, 2018 11:08 am
Contact:

Re: PowerShell based cmdlets / Commands

Post by c8h10n4o2 » Thu Nov 29, 2018 1:33 pm

I'm afraid not, looks like the module has to be updated to support that.

c8h10n4o2
Posts: 73
Joined: Thu Jan 18, 2018 11:08 am
Contact:

Re: PowerShell based cmdlets / Commands

Post by c8h10n4o2 » Thu Dec 06, 2018 8:42 am

@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" :-)

ArneG
Posts: 39
Joined: Thu Jan 18, 2018 11:08 am

Re: PowerShell based cmdlets / Commands

Post by ArneG » Thu Dec 06, 2018 11:50 am

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?

c8h10n4o2
Posts: 73
Joined: Thu Jan 18, 2018 11:08 am
Contact:

Re: PowerShell based cmdlets / Commands

Post by c8h10n4o2 » Thu Dec 06, 2018 12:40 pm

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 :-)

ArneG
Posts: 39
Joined: Thu Jan 18, 2018 11:08 am

Re: PowerShell based cmdlets / Commands

Post by ArneG » Thu Dec 06, 2018 1:37 pm

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 :)

c8h10n4o2
Posts: 73
Joined: Thu Jan 18, 2018 11:08 am
Contact:

Re: PowerShell based cmdlets / Commands

Post by c8h10n4o2 » Thu Dec 06, 2018 1:45 pm

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:

Code: Select all

Get-TDSensor | Get-TDSensorHistoryData | ConvertTo-TDNormalizedOutput | Export-Csv .\export.csv
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.

ArneG
Posts: 39
Joined: Thu Jan 18, 2018 11:08 am

Re: PowerShell based cmdlets / Commands

Post by ArneG » Thu Dec 06, 2018 2:34 pm

Almost there :)

Works fine when getting the complete history from all sensors, but when using switches -Deviceid and -After is does not work?

c8h10n4o2
Posts: 73
Joined: Thu Jan 18, 2018 11:08 am
Contact:

Re: PowerShell based cmdlets / Commands

Post by c8h10n4o2 » Thu Dec 06, 2018 2:47 pm

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:

Code: Select all

Get-TDSensor | Get-TDSensorData | ConvertTo-TDNormalizedOutput -PropertiesToAlwaysInclude RainRate, RainTotal, Temperature, Humidity
Hope that will help :-)

ArneG
Posts: 39
Joined: Thu Jan 18, 2018 11:08 am

Re: PowerShell based cmdlets / Commands

Post by ArneG » Thu Dec 06, 2018 3:19 pm

Select-Object : The property cannot be processed because the property "Raintotal" already exists.
At AutomaTD.psm1:317 char:20

But resulting csv looks okay..

c8h10n4o2
Posts: 73
Joined: Thu Jan 18, 2018 11:08 am
Contact:

Re: PowerShell based cmdlets / Commands

Post by c8h10n4o2 » Thu Dec 06, 2018 3:29 pm

That's what I get for using native .net instead to enhance performance :banghead:

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 :-)

ArneG
Posts: 39
Joined: Thu Jan 18, 2018 11:08 am

Re: PowerShell based cmdlets / Commands

Post by ArneG » Thu Dec 06, 2018 3:37 pm

Well, you did forget 'Humidity' this time? :D

c8h10n4o2
Posts: 73
Joined: Thu Jan 18, 2018 11:08 am
Contact:

Re: PowerShell based cmdlets / Commands

Post by c8h10n4o2 » Thu Dec 06, 2018 3:40 pm

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 :-)

ArneG
Posts: 39
Joined: Thu Jan 18, 2018 11:08 am

Re: PowerShell based cmdlets / Commands

Post by ArneG » Thu Dec 06, 2018 3:48 pm

I know, just checking to see that it was intentional :D

Post Reply