I have not tried it yet myself but there is a component called smth like “Ladybug Header”. Ideally you can use that to add the required header to the csv file that Honeybee requires to recognise it as its own.
P.S.: The InTable file report of Openstudio will not work afaik.
The answer is yes so long as you are requesting outputs from E+ in a CSV format (OutputControl:Table:Style,Comma;). You can do this with Openstudio and with most other E+ interfaces as far as I know.
All that you have to do is make a GH panel with the file address of the CSV and plug it into the “Read EP Result” component. If you request outputs that are non-standard in Honeybee, the data will be brought in through the “otherZoneData” or “otherSurfaceData” of the respective result-reading components.
Also important, make sure that the folder that contains the CSV result file also contains the .eio file output from E+. This is necessary to build up the header information on the imported E+ data.
If this is not working for you, please upload and example GH file with the issue and we will make sure it is fixed.
However, I still got the “Failed to parse the results file.” warning on the “read EP result” component when plug-in my own csv file generated from E+ simulation …
Appreciate you can kindly help to see if my csv file is missing something to be read:
I put in an extra check that should ensure that the result reader now works. I noticed that you generated the CSV file with an older version of the Honeybee components and this older version was not requesting the correct outputs for heating and cooling among a few others. For this reason, a bunch of the results are coming in under the “oterhZoneData” output in the attached GH file. You should update your HB components to the version on the github and generate a new CSV file if you want to avid this and have everything run smoothly.
I think I have the same difficulty with the readEPSurfaceResult component. The readEPResult is working just fine, tho.
Could it be because I hijack the simulationOutputs component and stuff in a bunch of other variables to report? This is a great, perhaps un-intended feature of Honeybee;) I use the extra variables in my post-processing. Obviously they aren’t getting read from the csv (on purpose) by the HB components, but perhaps they screw with the parsing routine?
If you are experiencing the same issue as Grasshope, see my response below. You have to request that surface data be written into the eio file if you are using an IDF not generated with honeybee. Do this by typing the following at the end of your IDF:
Output:Surfaces:List, Details; !- Report Type
I appreciate you using hydrashare but your file is so vast that I don’t know where you want me to look. Can you upload one that just focuses on the error you are having?
Let’s see. The IDF is generated by OS via the HB component. I checked the idf, and the output command is in there.
Here’s the point in the file where the component comes in (at the scribble “VIEW SURFACE RESULTS”):
Rather than chop down the file, I disabled the large swaths of stuff that don’t directly apply…which means the file is too big to attach here. if it’s not coming through hydra, here’s an old fashion dropbox link: