Moin,

.GroupBy(gr => new { gr.Id, (DateTime)EntityFunctions.TruncateTime(gr.MyDate), gr.MyValue }).Select(gr => new { gr.Sum(g => g.DeviceDay), gr.Key.DeviceId, gr.Key.TimeStamp}).toList();

>   
> Das klappt aber auch nicht, weil 1.: "(DateTime)EntityFunctions.TruncateTime" nicht in einem "GroupBy()" auftauschen darf und 2.: die Werte werden so nicht mehr groupiert.  
  
leider hast du nicht begründet bzw. die Fehlermeldung erwähnt, warum es nicht auftauchen darf, aber wenn überhaupt, dann müsstest du hier auch einen Membernamen vergeben (kann man nur bei Eigenschaften weglassen).  
  

> ~~~c#
  

> .GroupBy(gr => new { gr.Id, MyDate = (DateTime)EntityFunctions.TruncateTime(gr.MyDate), gr.MyValue }).Select(...);  
> 

Alternativ könntest du auch eine Zeichenfolge für den Gruppierungsschlüssel erstellen.

.GroupBy(gr => string.Format("{0}#{1}#{2}", gr.Id, (DateTime)EntityFunctions.TruncateTime(gr.MyDate), gr.MyValue )).Select(...);

  
Jetzt gibt es aber noch ein Problem, wo auch deddlfix schon nachgefragt hat. Programmierst du hier gegen Linq to Objects (IEnumerable) oder Linq to Whatever (IQueryable). Beim EntityFramework greift vornehmlich letzteres (also Linq to SQL). Natürlich kann man auch die Sachen miteinander vermischen, man muss sich halt nur darüber im Klaren sein. Bevor also auf dem Client Daten verarbeitet werden können, müssen sie auch vom Server zum Client übertragen werden. Daher wäre hier IQueryable performanter, weil der Server dann schon die verdichteten Ergebnisse liefert, aber man kann dann natürlich nicht die ganzen Client-Sachen nutzen (Zugriff auf Objekte im Cache vom Client-PC).  
  
Also ich bin kein EntityFramework-Guru, soweit ich weiss hat man hier ein Datenmodel auf dem Client, welches ein Datenmodel auf Server wiederspiegelt (SQL-Tabellen). Beim Erstellen der Modelle kann man das auch umgekehrt machen, also erst im EntityFramework Modelle erstellen und diese dann auf dem Server anlegen lassen. Es werden aber nicht nur die Modelle als Werteobjekte abgebildet, sogar die Beziehungen untereinander (Navigation-Property, Fremdschlüssel etc.). Na gut, es besteht wohl zwischen den Daten auf dem Client (die Entities) und den Daten auf dem Server (Daten in den Tabellen) eine bidirektionale Beziehung, glaub ich jedenfalls. Das EntityFramework managet management ... mänätscht das für dich :)  
  
Soll heissen, dass es vornehmlich die Linq-Anweisungen nach SQL übersetzt, zum Server schickt, die Ergebnisse abgrast und daraus wiederum Objekte im Speicher deinem Model entsprechend generiert.  
  
Wenn die Linq-Anweisungen also zwingend auf dem Client verarbeitet werden sollen, dann holt man sich die Daten von der IQueryable-Schnittstelle durch einen Aufruf der ToList-Methode (Alle Daten werden unter Umständen vom Server zum Client transferieren + Objekte erstellen).  
  
Sollten darin wiederum Zugriffe auf das EntityFramework erfolgen, dann werden zum entsprechenden Zeitpunkt wieder Daten vom Server geholt, um die entsprechenden Objekte zu erhalten.  
  
So, wiedermal mehr geschrieben als ich wollte. Ok, einen noch. Wenn du Fehler bekommst, dann ist es ziemlich nützlich diesen Fehler zu beschreiben und hier wäre auch eine Unterscheidung gut, ob der Fehler wärend der Kompilierung oder der Ausführung auftritt. Der Compiler weiss ziemlich gut, ob ein Zugriff auf dieses oder jenes Objekt im entsprechenden Kontext möglich ist oder nicht. Beim EntityFramework treten die Fehler meisten wärend der Kompilierung auf und meistens besagen diese, dass dieses Objekt oder die Art und Weise wie darauf zugegriffen wird nicht auf dem Server möglich ist. Das wiederum bedeutet, dass man wieder Linq to Objects und Linq to SQL vermischt hat.  
  
hth